I would have thought that the MacOS solution was the simplest, just make
the main thread the event thread - if you want to do something big, make
your own thread!
I tried that. It broke in way too many places.
Here are some very good thread guidelines from the Vinnie:Date: Tue, 28 Apr 1998 10:46:44 -0400
From: firstname.lastname@example.org (Vinnie Falco)
Subject: Re: Timers & Threads again…
Don’t use the multithread version of the C runtime library.
Don’t call standard C functions in the thread proc
Don’t do floating point conversions in the thread proc
He’s absolutely right. There are a couple of places where SDL event code
does ugly and potentialy dangerous things. X11 in particular is very
sensitive to being multi-threaded. It would be much safer and a bit faster
to move the event handling code into the main thread.
HOWEVER… this means that we would lose the functionality that I
developed async events for in the first place: The ability to chew
along blissfully, while other events are being handled transparently.
Unfortunately, as was made sadly apparent in the stars demo, you can’t
guarantee that an event thread will be serviced often enough, while if
you explicitly poll or wait for them, you’ll always get events when you
sigh Great idea, impractical for non-realtime OSs, I think.
Besides, it’s not really safe to do anything beside filter and change
the state of global variables from within event handlers anyway.
This solution may sound elegant Nathan, but it usually makes things worse:
This means there’s no elegant way of feeding events to the worker
threads… you’ll need synchronization & thus add unnecessary overhead. In
the end you might end up with something like OpenSTEP (ie. the display
server and the app-kit are not thread-safe there).
We should rather decide what we what: Do we really need async events? If
not, how can we simplify the mechanisms & what are the drawbacks. If Sam
takes the async events out now, there’s probably be no way back, as future
code may depend on certain behaviour.
I personally don’t consider async events necessary in SDL, as the type of
application (primarily games) usually process all their events centrally.
What do you others think? This is a very important design decision here.
-Sam Lantinga (slouken at devolution.com)