SDL_CreateMutex -> …
Message-ID: <52A2C80C.3060408 at icculus.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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.
I had thought that the audio callback was itself called by a
SDL-provided callback, but it looks like this isn’t the case. Would it
be difficult to rework the current system to a callback system,
perhaps by breaking the actual “working” bit of SDL_RunAudio() into a
prologue, loop body, and epilogue? I assume that the change would be
mostly useless, but it would work out conveniently for both OS
hobbyists and people who want to stay with single-threading for
whatever reason, when paired with a call to an appropriate
SDL_CreateThread wrapper (called create_thread() ?) in
open_audio_device() for implementing a single-threaded mode, since you
could just use *nix signals, or DOS interrupts, to write an overriding
implementation of the wrapper.
The only thing that I think wouldn’t work well with it is preemptive
threading on a platform that doesn’t have the ability to modify the
instruction pointer of an already running thread on the basis of some
action external to the thread itself. I believe that this sort of
thing is strickly in the Windows 3.0 and older sphere (and even then,
assuming that you can’t hook interrupts), so I doubt that it would be
a big stumbling block. Even on Win32, as long as you’re willing to use
SOME sort of Windows multi-tasking support (like fibers), or can stick
arbitrary code all over the place (such as if you’re writing a VM),
you should be able to make it work.
(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.)
Maybe it would be useful as a reference implementation?> Date: Sat, 07 Dec 2013 02:02:36 -0500
From: “Ryan C. Gordon”
To: SDL Development List
Subject: Re: [SDL] SDL_CreateMutex -> SDL_CreateSemaphore ->
Date: Sat, 7 Dec 2013 11:28:02 -0200
From: Gabriel Jacobo
To: SDL Development List
Subject: Re: [SDL] SDL_CreateMutex -> SDL_CreateSemaphore ->
SDL_CreateMutex -> …
Message-ID:
<CAKDfesmMdjPACT7Lt+DPrbsKs-bV_2J0+QXXO9icfW4BuU-irQ at mail.gmail.com>
Content-Type: text/plain; charset=“iso-8859-1”
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 that the only “bug” there is a failure to detect the
dependency loop and issue an informative message. I’m not sure exactly
where it occures, but I suspect that a simple preproccessor
conditional should do the trick.
Date: Sat, 7 Dec 2013 15:10:52 -0100
From: fungos
To: SDL Development List
Subject: Re: [SDL] SDL_CreateMutex -> SDL_CreateSemaphore ->
SDL_CreateMutex -> …
Message-ID:
<CAJ7KbxneGww+7A94yU531CXgrSz2OjWo-Uf+1wMcE4YcGWCbbg at mail.gmail.com>
Content-Type: text/plain; charset=“iso-8859-1”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.
What platforms do you support? Any that SDL2 doesn’t support out of
the box? I’m planning to eventually write a binding to a virtual
machine that I find interesting, but I personally have no intention of
removing any of the threading behavior, I just won’t provide a binding
for it instead (the virtual machine can already handle that…
basically).
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…
As in you don’t like to see the functionality duplicated? If so, I
feel that I should point out that SDL2 provides threads that work
reliably across platforms, while pthreads doesn’t, hence different
functionality 
.