wxsqueak mailing list

[Steven Swerling]

 > 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.

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).

I don't think there is a silver bullet that can make callbacks go away 
as a problem. But deferred events would help make it a very tractable 
problem.

The event