SDL_SemWaitTimeout performance

I’m seeing a large latency in returning from SDL_SemWaitTimeout on some platforms. I see from the source that in Windows it’s implemented as WaitForSingleObject, and on that platform it’s fine. However the implementation in the ‘pthread’ directory seems to depend on whether HAVE_SEM_TIMEDWAIT is defined; if not there’s a horrible fallback involving calling SDL_Delay(1) which would explain what I am seeing!

My question is, on what platform(s) is ‘sem_timedwait’ not available, and is there really no better alternative than spinning in a loop with SDL_Delay(1)? I’m using SDL_SemWaitTimeout to wake a thread on an event, and a latency of a millisecond is unacceptable from a performance standpoint.


What would that be in milliseconds? Note that the only guarantee of such timeouts is usually that it at least waits that long. It may take longer to wake/switch the thread for various reasons.


But does your SDL2 library actually take the SDL_Delay path? If you didn’t compile it yourself, is at least HAVE_SEM_TIMEDWAIT defined in SDL_config.h?

This function is in the POSIX.1-2001 specification. Reasonably modern Unix-like platforms should really have it.

At this point? No. SDL should not have to implement things that most platforms had for over a decade.

You have the option to create your own busy-loop with SDL_SemTryWait or atomics (if available on the platform) if you need to know immediately. The upside: It’s currently winter in the northern hemisphere.

I have no idea why you chose to reply in such an aggressive and unhelpful fashion, but I will certainly not trouble you or anybody else by making further enquiries here.


1 Like

Keep in mind that these guys are donating their time to SDL… and it is
made with LOTS of hard work and devotion. I think you’ll find in most
cases, if you really take a hard look at the implementation of various
things in the SDL source code, and the APIs they have to deal with to make
it all “magically” work on “everything”, these guys have done their
homework and produced quality code. Maybe not “perfect”, but quality
nonetheless. And, if you see something that isn’t quite up to par… you
have the source code and you can fix it yourself whenever needed!

So, you might consider cutting them some slack… :slight_smile:

Also, please don’t forget to submit your own improvements back to SDL for
the benefit of all whenever possible!

– Ed

Ed Phillips University of Delaware (302) 831-6082
Systems Programmer IV, Network and Systems Services

On Tue, 24 Oct 2017, rtrussell wrote regarding “Subject: Re: [SDL] Sdl
2.0.7 prerelease!”: