At 12:07 PM -0700 5/11/99, Alan Kennington wrote:
>Question: Is there indeed a thread-forking facility of some sort?
Not that you can use. This has come up before in this list, check the
archives for details. Basically, there aren't kernel resources allocated
to be able to fork. If you tried, it might appear to work but it would
occasionally trash memory. Don't even think of trying to do UI operations
from more than one task, the toolbox just isn't designed for it.
>Second question: Can user events be made to cause an alarm?
Alarms aren't processed asynchronously, so it really doesn't matter. They
just set up events to be handled next time through the event loop.
There are a couple of good ways to code the "watch for events" mechanism.
One is to write the computation code so that it saves state and only
processes a small chunk of data at a time. Then the event loop continues
to run with no event timeout and just calls the "DoMoreWork(stateP)"
function on nilEvents.
For the "worlds fastest scrabble" algorithm, a pretty good way to break up
the computation is by the anchor square. The routine to compute the best
move for a given anchor square is already fairly self contained, so you
just call that repeatedly for each anchor square and check for events in
between. (That's what I did for my Newton version of the scrabble
algorithm, and it worked great.)
The other way is a little more complicated -- you check for events inside
the algorithm, and if you find an event that needs processing (like a pen
down event in a particular area), you can put the event back on the event
queue and then return. The top-level form event handler will then get to
process the user event again.
This method has a couple of drawbacks: 1) if you don't call
SysHandleEvent, other stuff like alarms won't happen. 2) if you do call
SysHandleEvent (etc), then you're basically writing a nested event loop
inside your "DoWork" algorithm, and that's backwards. 3) it's tricky to
get the events processed just right -- some cause exit, some get ignored,
and some are re-queued for handling by a higher event loop.
--Bob