[SDL] sleeping better for lower latencies (and other things)

[Pierre Phaneuf]

On Fri, May 9, 2008 at 5:01 AM, Eddy Cullen <eac203 at ecs.soton.ac.uk> wrote:

>  From what I understand, one of the design decisions made, was to provide
> consistent behaviour across platforms. Due to restrictions on OS
> locking/threading semantics on some operating systems, SDL implements
> busy-waiting, even on platforms that support interaction with the scheduler.

There's some stuff that is *really* hard to get consistent semantics
right across multiple platforms. But this particular API
(SDL_WaitEvent) is quite simple: wait until the next event, as quietly
as possible. You could achieve that with an extra method in the video
driver dispatch table, and if it is NULL, fall back to the current
method of looping with the delay, it would only be better.

Note that this involves no interaction with the scheduler, just using
the platform API the most common way. On most platforms, there is a
blocking "wait for the next event" call (XNextEvent, GetMessage,
PhNextEvent, etc), which fits in quite naturally, and in most cases,
they also allow fitting that with waiting for other things
(ConnectionNumber with select, WaitForMultipleObject, PhEventArm and
PhEventRead). It isn't surprising and is quite natural, since that's
how most hardware in the last 20 years works (interrupt-driven).

Also, note that SDL_WaitEvent didn't really do real busy waiting, but
rather does "arbitrary waiting". This is better than busy waiting for
CPU usage (although worse than my approach), but mainly has terrible
latency effects. As for interactions with locking/threading semantics,
hardly any platforms have threads as a first class citizen, BeOS and
Java being exceptions, and from what I can see, that wasn't the best
idea ever (the best thing is to use a mix of threads and state
machines, with a low number of threads, too many threads leading to
excessive context switching, which Java finally found out and
addressed with NIO, at some point, and BeOS died before they could).

>  Possibly, the key issue is whether this decision should stand - perhaps
> additional APIs are required?

I'd just propose improving SDL_WaitEvent internally, with the exact
same semantics that it has currently, without big changes in
architecture (if I could do most of it from outside of SDL in my test
program, it's obviously not too far).

I'm also not too thrilled by the excessive reliance on the event
queue, which has some poor characteristics. On most platform, SDL
could get events directly from the platform, without any queueing, and
it would reduce the "losing events" effect (either platforms will be
sensible and not lose events, or they will lose them, and we'll be in
the same place as today), while letting proper event flow control work
(SDL_PumpEvents can lead an underlying event system to believe that an
SDL application is processing events quickly, when in fact SDL are
throwing them out as fast as possible, which is a loss of information,
leading to bad decisions on the part of the platform, in this case,
sending even more events!). We still need the event queue for
internally generated events (SDL_PushEvent), and when getting an
event, SDL would first look at the queue, and if it is empty, ask the
platform (possibly in a blocking way, if it is in SDL_WaitEvent).

>  As I write this, it all feels horribly familiar, like it's already been
> discussed on the group...

I'd be very interested in pointers as to that, actually. Often, there
is a reason for why things are in some way. I actually have rather
specific rules for whining and flaming (documented here:
http://www.advogato.org/person/pphaneuf/diary/118.html). In this
particular case, there is a tricky bit: I have personally done it (or
at least helped out doing it) better on Svgalib, X11 and Win32 (I
suspect it's possible on Mac OS "classic", since they're not exactly
thread-friendly in general). The documentation for Photon seems to
point that it is in fact designed for exactly this (QNX is often close
to the hardware, so it's not surprising).

But there's other platforms supported by SDL that might have different
restrictions that I do not know about. As I said, I'm still going with
at least category B ("whining is allowed if you can figure out a
better way"), and it'd be surprising if I was wrong, considering the
state of hardware in general, but there are some weird things out
there (*eyes WinCE suspiciously*)...

So I'm quite keen on finding out more about those other odd platforms. :-)

-- 
http://pphaneuf.livejournal.com/