[REBOL] Re: Aplication crashes - not sure why
From: sunandadh:aol at: 14-Apr-2002 4:42
> Hi folks, I have been working on a database front end in REBOL/View and
> while testing the display aspects for subform switching have managed to get
> rebol to crash (in Windows2000) on a regular basis
Nice looking buttons!
It's them waits in the action facets. You are creating simultaneous threads
and rebol don't like that much as yet.
Check the list archives for subject "multiple threads crash". Holger wrote in
Calling 'wait from within an awake handler is not really supported. It is
bad style anyway, because in event-driven systems event handlers are not
allowed to block. That's because blocking in an event handler makes programs
extremely difficult to debug, in particular if the list of handlers (meaning,
faces) is modified while another handler is suspended. The problem is that
all those suspended handlers carry hidden "context" around with them, and
you might end up with an "old" handler being woken up from suspension after
the face it has been associated with has already been removed from the
pane, by a different handler. Other complications are possible, as well. It
is extremely difficult to foresee all of these side effects, so programs that
use tricks like that are bound to be buggy and full of race conditions.
As for the crashes, this is the result of a limit on recursion in current
versions. Should be eliminated in one of the next version.
But you probably do want to keep the waits. That way a user can interrupt a
long-running action. Change them to wait 0, and you now have these two issues:
1. A long running process (such as running a monthly report) may create
multiple threads -- the user can click any other button while the action is
underway -- or even click multiple times on the same button.
To handle that, you need a global variable that tells you if you have an
action facet running. Check it at the start of every action. Return
immediately if it is true, otherwise set it and continue. Remember to unset
it at all the return points or the whole application gets blocked.
2. For good user relations (and the reason for wait 0 is), the user needs a
way to cancel a long-running action. My application (which looks similar to
your, but with less snazzy buttons) has a "Cancel button". If the user clicks
that, it sets a global "stop it" variable. Long-running action facets check
for this variable at regular intervals.