[view][crash] concurrent do-events limit.
[1/6] from: moliad:aei:ca at: 28-Mar-2004 15:44
FYI,
I have found a limit (not that its really limiting, but just that its THE limit)
on how many do-events you can call simultaneously.
that limit seems to be 12!
this means that if you try to go above 11 requesters deep (a requester which
opens a requester of its own), in standard VID, rebol WILL ALWAYS crash.
this is also the cause for crashing if you use VIEW instead of VIEW/NEW inside
buttons which open new windows as each call to view will call do-events.
There might be other things (like network or timer ports) which further reduce
that limit. I have not tested if its based on a limit with the PORT handling
itself, or an internal limit on ui-driven ports.
HTH!
-MAx
[2/6] from: atruter:labyrinth:au at: 29-Mar-2004 16:37
> I have found a limit (not that its really limiting, but just that its
> THE limit) on how many do-events you can call simultaneously.
> ...
> this is also the cause for crashing if you use VIEW instead of VIEW/NEW
Also note that *the* limit on opened windows is 256 (at least on Windows).
Regards,
Ashley
[3/6] from: maarten:vrijheid at: 29-Mar-2004 9:06
Maxim Olivier-Adlhoch wrote:
> FYI,
> I have found a limit (not that its really limiting, but just that its THE limit)
<<quoted lines omitted: 7>>
> that limit. I have not tested if its based on a limit with the PORT handling
> itself, or an internal limit on ui-driven ports.
Actually... the limit should be one, as a wait inside a wait is useless:
a wait is for event processing so one is enough. Nesting waits makes no
sense. As Carl once said: "a wait is a wait" ;-)
--Maarten
[4/6] from: moliad:aei:ca at: 29-Mar-2004 4:06
Hi Maarten,
> Actually... the limit should be one, as a wait inside a wait is useless:
> a wait is for event processing so one is enough. Nesting waits makes no
> sense. As Carl once said: "a wait is a wait" ;-)
I agree, which is why it took me so much time to understand how the modal system
all works in view.
but when you open any of the requesters (inform), it calls a new 'do-events (
wait [] )... simply because you don't want it to return right away...
the wake-event will return false whenever hide-popup is called. This ends one
of the concurrents do-event wait []...
I also, just today, realised that the 'view word is not a native!
anyways, I managed to patch the popup system so that resizable modal requesters
are now possible...
vid, view and face are so open, its nice to be able to fix/enhance things
ourselves. !
-MAx
[5/6] from: rotenca::telvia::it at: 29-Mar-2004 14:11
Hi Maxin and Marteens,
> Actually... the limit should be one, as a wait inside a wait is useless:
> a wait is for event processing so one is enough. Nesting waits makes no
> sense. As Carl once said: "a wait is a wait" ;-)
Nesting makes sense: it is useful to let the system know where to go when the
wait finish. Rebol handle this with nested wait. This is a standard behaviour
used by the modal system which is usually called from event code.
And this does not crash Rebol as Holger one time said (at least seems to me).
The crash pointed by Maxim is already in tracker (#84): you can see what Carl
says about it in the Notes section of the bug.
Obviously this can be handled in another way, building a chain of filter
function in one wait loop, but this is not the actual rebol implementation.
---
Ciao
Romano
[6/6] from: maximo:meteorstudios at: 29-Mar-2004 11:57
> Nesting makes sense: it is useful to let the system know
> where to go when the
> wait finish. Rebol handle this with nested wait.
It does make the modal interface much easier to use/change/tweak.
I had built an event blocker before, without knowing how the current system does it,
and I must admit that the current system makes a popup menu trivial to write.
> The crash pointed by Maxim is already in tracker (#84): you
> can see what Carl
> says about it in the Notes section of the bug.
-MAx
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted