Possibly fixes #1422 (event queue overflow) #116
Conversation
Event list expansion was added by Atronix to deal with bug #1422. Original expansion set EVENT_LIMIT to 0xFFFF REB_EVENT values (64k). This was much larger than the hard limit of 128 set by original open-source Rebol. But adding `SET_SIGNAL(SIG_EVENT_PORT)` in `Append_Event()` corrected the bug and allowed the limit to be lowered. Still the chunking/expansion mechanic is retained.
There was a problem hiding this comment.
This will cause unexpected recursions. Think about a button with an action function. When the button is clicked, the action function could call Do_Singals and then Awake_System, which handles the pending events. If there are some pending clicks on this button, the same action function will then be called and cause recursive calls. This is similar to the recursion I wanted to avoid with wait/only.
Basically, we'd like the Awake_System is only be called from WAIT, so that the user knows there is only one place that event handling could happen.
There was a problem hiding this comment.
Hmmm... I see. But perhaps should it be not just WAIT, but also at sort of the "top level loop" (e.g. if you get back to the REPL)?
e5d8945 to
5a309e2
Compare
132f7e8 to
4872244
Compare
f8a260d to
8da92d3
Compare
052dc8b to
3f9978e
Compare
80fd3a0 to
3b8a482
Compare
|
Closing because this apparently doesn't completely solve the problem, and because Ren-C is aiming to become agnostic to the event system used by the host. Hence this is not a priority concern. |
Event list expansion was added by Atronix to deal with bug #1422.
Original expansion set EVENT_LIMIT to 0xFFFF REB_EVENT values (64k).
This was much larger than the hard limit of 128 set by original
open-source Rebol. But adding
SET_SIGNAL(SIG_EVENT_PORT)inAppend_Event()corrected the bug and allowed the limit to belowered. Still the chunking/expansion mechanic is retained.