[SDL] Re: Some multithreaded improvement to the event queue...

Antonio SJ Musumeci asm3072 at njit.edu
Wed Sep 14 08:40:20 PDT 2005


Question... (without looking at the code) why is it that the size of the 
event queue a compile time option?

Marc Daya wrote:
>>And, indeed, on platforms which /do/ support threads, the 
>>actual semantics
>>are left unchanged:  SDL_WaitEvent() will return faster once 
>>an event is
>>available and not hog (part of) the CPU while it waits, but 
>>will otherwise
>>act exactly as it always had.
> 
> 
> this is a change that i, for one, (for what its worth) would like to
> see in SDL.  is there somewhere other than this list that one can
> watch to determine which patches have been accepted?
>  
> 
>>The only other change (not dropping events when the queue is full) is
>>arguably a bugfix.  I wouldn't expect any library user is legitimately
>>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.
> 
> are there not consequences to blocking the event delivery thread?
> won't this result in the application appearing unresponsive to the OS?
> 
> assuming SDL handles certain events before putting them on the queue
> (like redrawing when focus is gained), the application may continue to
> appear to be OK and be given a chance to recover.  if the queue filled
> up because of a temporary processing blip, then this may be desirable.
> 
> just thinking out loud...
> .marc
> 
> _______________________________________________
> SDL mailing list
> SDL at libsdl.org
> http://www.libsdl.org/mailman/listinfo/sdl
> 




More information about the SDL mailing list