May be lessions of 1(thread) to 1(thread), 1 to many, manay to manay?
Anyway, when I get time to read over your source code, I will
provide some example for it, I may try to port your CheatThread to
Gameboy Advance, since I am developing a Simple OS for GBA to drive
my GUI interface.


--- In cheapthreads@yahoogroups.com, Scott McKellar <mck9@s...>
wrote:
> See response below...
>
> gordonwkf wrote:
> >
> > Dear Sir
> > Can you write more doc for funciton prototypes' parameters?
Which
> > make it more easy to use? Are there any more examples?
> >
> > Gordon From Hong Kong
> > thx
>
> I tried to provide detailed documentation, but there's always
> room for improvement.
>
> Which parameters are you having problems with?
>
> As for examples...
>
> One weakness of the website, as it stands now, is that it has only
> one example -- the cttimer program, which may be too simple to be
> very helpful.
>
> I'm not sure how to provide good examples. In order to demonstrate
> anything beyond the simplest concepts, a program may have to be
> complicated enough that it's hard to follow. Just to have one
> thread send a message to another, I need to create the threads
> and call ct_schedule(). Then one of the threads has to send a
> message, and the other has to receive it and somehow show that it
> has received it. Then they have to both terminate or go to sleep,
> or one of them has to call ct_halt(). I don't know how many people
> would want to wade through several hundred lines of code just to
> see an example of one simple thing.
>
> Another problem is that it's hard to show that multiple threads are
> running without some kind of graphical display. The main program
> that I use for testing puts some blinking lights on the screen,
one
> thread per light, plus a couple of other threads to read the
> keyboard and control the timing of the blinks. However this
program
> depends on some compiler-specific function calls for controlling
the
> display. I don't want to use it for an example because it's not
> portable. About all I can do portably is to have different
threads
> write different lines of text. That's not very exciting, but I'm
> not sure how to do better.
>
> The attachment contains an example slightly more complex than the
> cttimer program. Two threads take turns writing to standard
output.
> Each thread runs for a different number of iterations. The main
thing
> that this program demonstrates is that two threads can run the
same
> code but behave differently, because they store different values
in
> their thread-private data.
>
> In order to get the attachment you may need to be a member of the
> mailing list (I don't know exactly how Yahoo handles attachments).
> One of these days I'm planning to put this example up on the
website.
> Until then, if you're not a member you can ask me for a copy by
> private email.
>
> Scott McKellar mck9@s...
> http://home.swbell.net/mck9/ct/