Aplication crashes - not sure why
[1/8] from: james:mustard at: 14-Apr-2002 13:31
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. I tried using recycle
but it doesnt seem to recycle fast enough..
The script is at: http://www.mustard.co.nz/rebol/main.r
To reproduce the behaviour just click back and foward between the "DEBTOR
ENQUIRIES", "LOAD NEW CASES" and "PAYMENT LOADING" buttons.
While rapid switching is not a daily occurrance it could happen and so is
therefore of some concern.
The eventual goal is to be able to reproduce Microsoft Access's form
behaviour in Rebol for a more cross-platform solution.
PS: The test machine is a AMD 1.4 with 384mb RAM. Please excuse the
gradients (or remove them) if it performs slowly.
Regards,
James
[2/8] from: sunandadh:aol at: 14-Apr-2002 4:42
James:
> 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
that thread:
<<
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
REBOL
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.
Sunanda.
[3/8] from: gchiu:compkarori at: 14-Apr-2002 21:06
On Sun, 14 Apr 2002 13:31:32 +1200
"James Marsden" <[james--mustard--co--nz]> wrote:
> 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. I
IOS also crashes under XP.
--
Graham Chiu
[4/8] from: james:mustard at: 14-Apr-2002 22:54
Sunanda wrote:
> Nice looking buttons!
Thanks ;-) They are temporary until I create aqua style glass buttons with
a greyscale effect.
> It's them waits in the action facets. You are creating simultaneous
threads
> and rebol don't like that much as yet.
>
Ah hah.. Bad design on my part.
> Check the list archives for subject "multiple threads crash". Holger wrote
in
> that thread:
<snip>
Hmm.. I am used to the VisualBasic/Access event model where i can use local
static variables within event handlers to act as blocks to avoid event
collisions.
eg:
sub event_ontimer()
static busy as boolean
if busy then exit sub
busy = true
... event code ...
busy = false
end sub
The waits were an attempt to stop repeated event firing - I assumed
(wrongly) that the event would be locked. Of course it wouldn't be on
hindsight and I would need to implement a blocker system like I
traditionally do in VB/Access.
As i was unsure how to apply static local variables in rebol (without
building objects to store them in..) I wrongly chose to use wait.
Perhaps it would just be tidier to build an object and store blocking flags
for each event...
> 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.
I prefer localised blockers to avoid application lockup and easier
maintenance.
> 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.
Hmm.. probably a good idea that - having a global die flag for action
handlers. Will give it a go.
Regards,
James
[5/8] from: james:mustard at: 14-Apr-2002 23:09
Well, its all fixed now :) Amazing how you miss the small things sometimes
:)
Here is the method I implemented:
box with [block-engage: false] feel [
engage: func [f a e][
if not f/block-engage [
f/block-engage: true
if a = 'down [f/effect: [gradient 1x0 150.150.150
128.255.128] show f wait 0]
if a = 'up [f/effect: [gradient 1x0 150.150.150
196.196.196] show f wait 0]
f/block-engage: false
]
]
]
For a link to the now working code go here:
www.mustard.co.nz/rebol/fixed-main.r
[6/8] from: sunandadh:aol at: 14-Apr-2002 8:36
James:
> > It's them waits in the action facets. You are creating simultaneous
> threads
> > and rebol don't like that much as yet.
> >
>
> Ah hah.. Bad design on my part
Not really -- the threading model is neither well explained nor
(consequently) well-understood. And, with a bit of luck (given Holger's
hints), it'll change for the better in a new release. You had no way of
knowing, and were fortunate that your testing caught the problem so quickly.
I've spun off the cliff numerous times coding fast round a tight Rebol
learning curve. It's part of the charm of the language -- if you have the
luxury to spend that amount of time learning from mistakes.
Sunanda.
[7/8] from: holger::rebol::net at: 14-Apr-2002 9:26
On Sun, Apr 14, 2002 at 09:06:56PM +1200, Graham Chiu wrote:
> On Sun, 14 Apr 2002 13:31:32 +1200
> "James Marsden" <[james--mustard--co--nz]> wrote:
<<quoted lines omitted: 4>>
> > rebol to crash (in Windows2000) on a regular basis. I
> IOS also crashes under XP.
Not here. If you get crashes in IOS then please report them through
the bug report mechanism in IOS.
--
Holger Kruse
[kruse--nordicglobal--com]
[8/8] from: gchiu:compkarori at: 16-Apr-2002 18:46
On Sun, 14 Apr 2002 09:26:07 -0700
Holger Kruse <[holger--rebol--net]> wrote:
> > > have managed to get
> > > rebol to crash (in Windows2000) on a regular basis.
<<quoted lines omitted: 4>>
> them through
> the bug report mechanism in IOS.
Ooops, missed a comma.
I meant to say, James' code also crashes in IOS running in
XP.
--
Graham Chiu
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted