wxsqueak mailing list
sswerling at yahoo.com
Wed Feb 23 00:58:52 UTC 2005
> 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
More information about the Wxsqueak