In looking to solidify the design of the conditional variables for Unix
platforms I was thinking of going the route of linuxthreads on systems
that don’t support POSIX threads.
Basically, the SIGUSR1 and SIGUSR2 signals are used as signaling
mechanisms to start/stop threads and perform other tasks.
Now, this is a condition of using threads on Linux. You can’t use those
signals.
What about other Unix platforms? Is there any real objection to making
that a condition of using conditional variables in SDL? (It would keep me
from having to maintain semaphores for the thread signaling mechanism.)
I am waiting to actually release any final proposal until the next stable
release that Sam sends out. I figured that way if it gets accepted for
consideration (please? [grin]) it’s got a full development cycle to be
ironed out for Win32 and BeOS. (The Unix support is really quit stable.)
Also, instead of making the application include an SDL_cond.h file I
thought it might be easier to roll it into SDL_mutex.[hc] as it follows
the same rules of portability as the mutex code does.
Paul Braman
@Paul_Braman
Oops. 
From SDL_audio.c
#define ALERT_SIG SIGUSR2
Guess SDL already uses one of these. Suppose it wouldn’t hurt to grab
SIGUSR1 as well.
(Note, this only applies to BeOS, apparently. Systems not supporting
POSIX threads don’t support SDL threads. While mutexes still might be
available, conditional variables just don’t make any sense. However, BeOS
might not support POSIX threads but it looks like it supports POSIX signal
semantics. Not really sure about Irix, though. Dunno what that sproc()
system call does. It looks like it creates a thread but I dunno if
mutexes are supported or not. Maybe they use the linux-directory
SDL_mutex.c without POSIX threads? Another good candidate for this
design.)
As for Win32…ummm…
Paul Braman
@Paul_Braman
Paul Braman wrote:
In looking to solidify the design of the conditional variables for Unix
platforms I was thinking of going the route of linuxthreads on systems
that don’t support POSIX threads.
Basically, the SIGUSR1 and SIGUSR2 signals are used as signaling
mechanisms to start/stop threads and perform other tasks.
Now, this is a condition of using threads on Linux. You can’t use those
signals.
What about other Unix platforms? Is there any real objection to making
that a condition of using conditional variables in SDL? (It would keep me
from having to maintain semaphores for the thread signaling mechanism.)
I am waiting to actually release any final proposal until the next stable
release that Sam sends out. I figured that way if it gets accepted for
consideration (please? [grin]) it’s got a full development cycle to be
ironed out for Win32 and BeOS. (The Unix support is really quit stable.)
Also, instead of making the application include an SDL_cond.h file I
thought it might be easier to roll it into SDL_mutex.[hc] as it follows
the same rules of portability as the mutex code does.
stupid question:
why does SDL have it’s own thread/mutex management instead of using
posix threads ? for platforms which don’t support posix threads, one
could write an pthread-lib.
so also many other programs which are not using SDL could also
benefit fom it.
bye,
ew.
stupid question:
why does SDL have it’s own thread/mutex management instead of using
posix threads ? for platforms which don’t support posix threads, one
could write an pthread-lib.
Posix threads is a fairly large and complex API. Many of the platforms
supported by SDL did not have a working Posix thread implementation at
the time I wrote it (including Linux). So I went with the minimum necessary
bloat and work.
-Sam Lantinga (slouken at devolution.com)
Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec