I wonder if people knowing various platforms would care to report coupling
between threads and services?
For example, I believe that, on Windows, only the main thread of an application
gets keyboard events. However on Windows, any thread can read another threads
Sam tells me OSX has similar issues.
AFAIK on Linux any thread can read events from Xlib and any thread can also
write to OpenGL context?
The reason for my query is this: ideally, one could solve the problem created by these
platforms by coding a single (platform dependent) event loop in the main thread,
and making all the usual SDL code run in another thread. This puts SDL completely
in control of I/O and normalises the interface.
There are two problems doing this that I can see:
- Some small console devices don’t have threads
- Buffering graphics to OpenGL devices is too slow
Point 2 means: if you can’t do graphics from a non-main thread,
the mechanism can’t work because the performance penalty for
delivering packaged operations from the client thread to the
mainline thread would be too high.
However on Xlib on Linux at least this seems not to be necessary?
SDL uses things like SDL_PumpEvents to fix this. You can read the SDL
event queue from any thread, the pumping is there to fixup the problem with
the underlying platform if it doesn’t allow non-main thread to read the
event queue. Clearly this is not so good because you have to call
it in various places to ensure response to the KB is reasonable.
The problem goes way if the main thread loops around calling
SDL_PumpEvents and the client program is in another thread.
Similarly issue with audio and any other device where I/O is constrained
by the platform to the main thread.
Packaged graphics is fine for a GUI … after all X windows does exactly that.
But I doubt it would fly for high performance rendering. Maybe I’m wrong
on that too?–