Deferred events

[Rob Gayvert]

Steven Swerling wrote:

>
> > Don't stop harping on this;
>
> Ok, since you asked :)
>
>>> Using deferred events should definitely help prevent crashes, and as 
>>> a general policy should be used for anything that takes any 
>>> appreciable amount of time. But I'm not sure what will happen in 
>>> this scenario if events aren't disabled or consumed in some way. If 
>>> they pile up in the wx queue while the deferred event is being 
>>> handled, there's no easy way to ignore them. Should each deferred 
>>> event be handled in its own process? That would prevent wx events 
>>> from queing up, but would it make it harder to deal with at the 
>>> application level?
>>
>
> No, I would just use a SharedQueue to store the deferred events as 
> they come in, and have another process whirring away that plucks the 
> deferred events one by one and executes them. That's how WorldState's 
> deferred queue works, and I believe that's how Digitalk/v handled it. 
> Having one process per event will likely get you some synchronization 
> problems.

Ah, that answers the remaining question I had about how to implement 
this. I could see 3 ways of processing the deferred events: (a) 
synchronously before other wx events in the current event process; (b) 
in a single separate process; or (c) each in a separate process. The 
first looks too strict, and the third too lenient, so the second one 
must be right.

> At this point you've shifted the burden to the app developer. There is 
> always the possibility that a deferred event and a sync event get in a 
> tug of war over some data. But that's the way Digitalk/V dealt with it 
> -- you're already way ahead of them, since in Digi you would crash the 
> image if there was a walkback during a callback. I remember their 
> advice to developers overriding windows callbacks was quite simple -- 
> get out fast, or pay the consequences. And it worked. In practice, it 
> really wasn't hard to deal with. It worked.
>
> Picture this scenario. Say a developer hooks up a button click event 
> to load and start an mpeg movie. The load and startup take awhile, so 
> it is hooked up as a "deferred" event. The handleEvent: method sees 
> that it's a deferred event and queues it up, returning from the 
> method. The developer doesn't use an hourglass cursor, and the user 
> doesn't know whats going on, so he clicks the button about 50 times. 
> Boom, 50 "startVideo" commands are queued up.
>
> But the app developer was smart enough to put a check at the top of 
> his #startVideo method that checks to see if the video is already 
> loaded, and exit the method if it's already going, just outputting a 
> status message blinking "Currently loading my.mpeg" for the subsequent 
> 49 events (which therefore execute almost instantly).

Or you could also just disable the button, no?  The scenario that Cees 
describes with a lengthy database query is very similar. If the handler 
is executing Smalltalk code, then subsequent clicks elsewhere could 
likewise be handled immediately and either ignored or with some kind of 
busy response. But what if it's off in a primitive or FFI call for an 
extended period? I don't know what the wx core will do with clicks or 
keystrokes in this case.  Maybe there's something we can use here from 
the implementation of WxWindowDisabler.