Hello George,
Instead of wading into the murky waters of trying to munge with Palm
multi threading, have you considered using a different paradigm? For
example, you could process nil events, and use a state machine to decide
which "thread" to run, where your "thread" would become a function with
some state info to remember where it left off. Perhaps there are more
elegant ways of doing this, but it's worth considering.
Adrien.
Lin George wrote:
Hello Roger, I appreciate your help and others as well. I understand your
points and they are helpful. But what I want to do it to port some Windows
Mobile applications, which use true multi-task (multi-thread more accurately).
The differences of multi-task senses between my application and the solution
you mentioned are,
1. Not a hacking way by using un-documented features;
2. Callback function is not working in all cases of a true multi-threaded (for
example, an elegant producer -- consumer case, backtest sample in financial
stock exchange simulation -- one thread to simulate one user to make stock
deal, other types of games ...). Because callback function works on per
notification basis, but multi-task application concept is beyond that.
What I concern is the *true* multi-task environment, which supports generally
all kinds of multi-threaded application (for example, the two samples I listed
above). Could Palm OS 5.2 be capable of doing it?
regards,
George
--
For information on using the PalmSource Developer Forums, or to unsubscribe,
please see http://www.palmos.com/dev/support/forums/
