tjmonk15 wrote:
onlyonemac wrote:
For what it's worth, I tend to perform my own "thread" management when I write in userspace. Probably a bad idea, since I can only take advantage of one core, but in the days when desktop CPUs only had a single core the system worked nicely, as I had complete control over what tasks I performed and in what order I performed them. By managing one's own threads, once can avoid a lot of annoying race conditions that otherwise require hackish workarounds (I'm thinking right now about that SDL-based game I'm writing, and the timer callback runs in a separate thread so to avoid a race condition with the keypress handler I have to make the callback post a user event to the event loop and then perform the "real" operation in the event handler).
Sounds more like you are trying to ignore the host OS methods of dealing with User Interaction. (Or you don't know how to queue events yourself)
- Monk
That's exactly my point: I shouldn't have to queue my own events just to get around a race condition caused by OS-level multithreading. And before you shoot me for writing a keypress handler, remember that this is a game where I need to be able to detect actual key-down and key-up events to implement e.g. continuous movement of a character, and I'm using SDL where handling keypress events manually is the standard way to do things; needless to say these are SDL events, not low-level hardware events, so it's not like I'm writing a PS/2 driver to run in userspace lol.