This is not directly related to this discussion per se, but I wanted to
voice an opinion on the subject of threads within an application. (I
assume this is well known to everyone, but I just want to emphasize
it...)
I just wanted to point out that within your own* program, it's well
workable to multitask your own code directly. Yes, that involves a
little more programming than the abstraction of having threads, but it
is much easier to debug, and you have absolute control over how the code
(and processing time) gets broken up. (Look at SimCity, for example.)
*(For inter-program tasking, interrupts and callbacks do wonders.)
I cringe every time I see that Palm comment that says that the Palm
doesn't lend itself to a spreadsheet in part because you can't do
background calculations without threads [didn't Excel go a decade
without threads?]. Every OS I've ever used has paid a stiff performance
price for implementing pre-emptive multitasking (threads or processes),
and it pains me to see modern progammers so reliant on threads.
Perhaps the PalmOS could implement thread-like macros that made you feel
like you had threads while executing cooperative mutitasking via stack
swapping. Or a more automatic solution (with less control) is to have
the compiler insert "multitasking" code for you on compile. Either way,
interrupts would still be there to handle a program that either crashed
or was choosing to hog the processor beyond means (arcade mode).
But of course, as we all already know, Palm is aiming for a 200 MHz
StrongArm so they can add pre-emption while maintaining the current
application speed of Palms.
OK, I had my old-timer two cents moment. :)
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
