[SDL] RE: Re: Some multithreaded improvement to the event queue...
Marc A. Pelletier
marc at abovesecurity.com
Wed Sep 14 06:23:42 PDT 2005
Marc Daya wrote:
>> The only other change (not dropping events when the queue is full)
>> relying on events being lost. :-)
> and argue i shall ;) well, perhaps not argue so much as clear my own
> misunderstandings of how SDL works...
> while i agree that no user should be relying on events being lost when
> the queue is full, i think its a good way to handle a bad situation.
> it is, to me, the least error-prone way of handling such a situation.
It might have been, perhaps, given a bit of smartness: you might want to
cumulate mouse movement, perhaps, or drop event /pairs/ which cancel each
other. But you really wouldn't want to drop, say, a key release event if
you kept the key press. (key repeat anyone?) But the decision on what
events are "worth" keeping is best left to application logic-- a painting
program might really want to keep all mouse motion but not care so much
about the keyboard, etc.
> are there not consequences to blocking the event delivery thread?
> won't this result in the application appearing unresponsive to the OS?
It cannot be any worse than just not asking for the EVENTTHREAD at
SDL_Init(): events are just polled everytime you SDL_WaitEvent() or
SDL_PollEvent(). If your code is busy doing something else, it's not
polling at all (rather than being able to snarf as many events as would
fill the queue before it has to stop).
The net effect is that your application would appear _more_ responsive to
Incidentally, I'm no Win32 expert, but my impression was that the
determination that an application "has stopped responding" was only done
upon specific user action (trying to close the app, etc) and that there was
a sizable delay in making that determination. Arguably, (yes, feel free to
argue again) :-) a program which has completely stopped draining events
from the queue for several seconds and that the user is actively trying to
kill *is* no longer responding.
-- Marc A. Pelletier
More information about the SDL