SDL_CreateMutex -> SDL_CreateSemaphore -> SDL_CreateMutex ->

SDL Development
1

Hi,

I’m trying to compile SDL not using autotools and I’m not sure about the
threads usage in SDL2.

First, I would prefer to use c11 threads, so I would like to not permit the
use of SDL threads at all, but I’m not sure how to do this, when using
SDL_THREADS_DISABLE I get this message: "SDL not built with thread support"
and SDL_init fails. So, I get to the second issue:

Trying to compile with threads but using only generic/* and not pthreads/*
I got a infinite recursion between CreateMutex and CreateSemaphore.

I would like to know exactly what is needed in terms o threads to get SDL2
working (generics + pthreads?), so why have the option to not use pthreads?
And how to get it working? :slight_smile:

Thank you!!!

2

I’m trying to compile SDL not using autotools and I’m not sure about the
threads usage in SDL2.

Are you rolling your own build system here, or using CMake, or…?

I’ve been told that SDL2 on Windows actually compiles cleanly out of the
box by just pushing the .c files through the compiler as-is, but I can’t
confirm that. On Unix/Linux systems (places that would need pthreads), I
can’t imagine rolling a stable build system for all the things our build
systems do is much fun.

First, I would prefer to use c11 threads, so I would like to not permit
the use of SDL threads at all, but I’m not sure how to do this, when
using SDL_THREADS_DISABLE I get this message: “SDL not built with thread
support” and SDL_init fails. So, I get to the second issue:

That specific error is probably a bug in our build system, because it’s
extremely rare that someone would build SDL2 without thread support.

Is there a reason you want no SDL threads at all? At a minimum, it’ll
break the audio subsystem and a few other things, even if we fix the
SDL_Init() bug you mentioned.

Trying to compile with threads but using only generic/* and not
pthreads/* I got a infinite recursion between CreateMutex and
CreateSemaphore.

The generic code is meant to be used when the system doesn’t provide all
the facilities we’d expect, so we build off the ones they do provide.

I would like to know exactly what is needed in terms o threads to get
SDL2 working (generics + pthreads?), so why have the option to not use
pthreads? And how to get it working? :slight_smile:

Not having pthreads probably goes back a long long way to when threads
were a new thing in Linux, or perhaps for crusty Unix variants that
didn’t support them at all. It’s not really surprising to me that
changing these defaults breaks things in SDL2, as you’re trying to flip
a switch that hasn’t been flipped in over a decade.

I would say: let it build with full pthread support, and if you’d rather
your app uses c11 threads, then just use them instead in your app. The
handful of things that use a thread internally in SDL will still use SDL
threads internally, but everything will just be pthreads under the hood
anyhow. :slight_smile:

(although a c11 thread backend in SDL, as a fallback for systems without
pthreads, etc, might be interesting, but I’m not sure what platforms it
would cover that we don’t already have, at least in current times.)

–ryan.

3

2013/12/7 Ryan C. Gordon

I’m trying to compile SDL not using autotools and I’m not sure about the

threads usage in SDL2.

Are you rolling your own build system here, or using CMake, or…?

I’ve been told that SDL2 on Windows actually compiles cleanly out of the
box by just pushing the .c files through the compiler as-is, but I can’t
confirm that. On Unix/Linux systems (places that would need pthreads), I
can’t imagine rolling a stable build system for all the things our build
systems do is much fun.

First, I would prefer to use c11 threads, so I would like to not permit

the use of SDL threads at all, but I’m not sure how to do this, when
using SDL_THREADS_DISABLE I get this message: “SDL not built with thread
support” and SDL_init fails. So, I get to the second issue:

That specific error is probably a bug in our build system, because it’s
extremely rare that someone would build SDL2 without thread support.

Is there a reason you want no SDL threads at all? At a minimum, it’ll break

the audio subsystem and a few other things, even if we fix the SDL_Init()
bug you mentioned.

The event loop also uses a locking mechanism which IIRC (from when I tried
to see if we could get the library to compile using strict C89), also
depends on the thread functionality. So it makes sense that SDL refuses to
work without threading support.

Trying to compile with threads but using only generic/* and not

pthreads/* I got a infinite recursion between CreateMutex and
CreateSemaphore.

The generic code is meant to be used when the system doesn’t provide all
the facilities we’d expect, so we build off the ones they do provide.

Yep, you need either a Mutex or Semaphore implementation, the infinite
recursion is probably a bug we can fix. I think the only way to get rid of
pthreads, if one is so inclined, is to provide a threading background based
on c11 threads.–
Gabriel.

4

Yes, I have a big open source library blob here (all mit, zlib, bsd and the
variations) that I let compiled and ready for all platforms that I support,
SDL2 is getting into this lib right now. And I do not use anything more
than video and input from SDL and/or GLFW (also in my blob). Threads and
audio are not needed anyway.

At least this helped find two possible bugs with SDL2, so I’m already
satisfied :slight_smile:
Anyway, would be nice to fix the issue when disabling threads or
effectively remove this option if nobody used for the last 10 years…
The recursion betwen semaphore and mutex in the generic implementation
also, as it can be very frustrating and a blocker if anyone gets there too.

So, in general, I think your build system should detect a c11 compliant
compiler and change automatically from pthreads to c11 threads and remove
the option for disabling threads. c11 threads are nothing more than
pthreads, the spec is based over pthreads API and the lib internally "is"
pthreads (on posix) or other system native threads (windows threads as-is).
So, c11 threads already does the job you’re doing with SDL_thread*. Should
I say that my OCD does not like two pthreads versions… :smiley:

Anyway, this is a minor problem… just passed here to confirm and maybe
show a possible bug. If time permits I may implement c11 threads or just
ignore all this and keep going.

Thank you for you responses, it was really helpful!On Sat, Dec 7, 2013 at 12:28 PM, Gabriel Jacobo wrote:

2013/12/7 Ryan C. Gordon

I’m trying to compile SDL not using autotools and I’m not sure about the

threads usage in SDL2.

Are you rolling your own build system here, or using CMake, or…?

I’ve been told that SDL2 on Windows actually compiles cleanly out of the
box by just pushing the .c files through the compiler as-is, but I can’t
confirm that. On Unix/Linux systems (places that would need pthreads), I
can’t imagine rolling a stable build system for all the things our build
systems do is much fun.

First, I would prefer to use c11 threads, so I would like to not permit

the use of SDL threads at all, but I’m not sure how to do this, when
using SDL_THREADS_DISABLE I get this message: “SDL not built with thread
support” and SDL_init fails. So, I get to the second issue:

That specific error is probably a bug in our build system, because it’s
extremely rare that someone would build SDL2 without thread support.

Is there a reason you want no SDL threads at all? At a minimum, it’ll

break the audio subsystem and a few other things, even if we fix the
SDL_Init() bug you mentioned.

The event loop also uses a locking mechanism which IIRC (from when I tried
to see if we could get the library to compile using strict C89), also
depends on the thread functionality. So it makes sense that SDL refuses to
work without threading support.

Trying to compile with threads but using only generic/* and not

pthreads/* I got a infinite recursion between CreateMutex and
CreateSemaphore.

The generic code is meant to be used when the system doesn’t provide all
the facilities we’d expect, so we build off the ones they do provide.

Yep, you need either a Mutex or Semaphore implementation, the infinite
recursion is probably a bug we can fix. I think the only way to get rid of
pthreads, if one is so inclined, is to provide a threading background based
on c11 threads.

–
Gabriel.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
Animal Liberation Front
http://www.animal-liberation.com/