Subject: Re: libpthread busted?
To: Thor Lancelot Simon <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 03/05/2003 11:10:00
On Wed, 5 Mar 2003, Bill Studenmund wrote:
> Well, that's not what's going on here. The SLD folks wanted to make a
> library that, if it's used in a threaded app, will work right, and if it's
> used in a non-threaded app, will ALSO work right.
It's been brought to my attention that it's not that simple. I'll see if I
now have it right (or at least closer). I expect to be corrected to the
extent I'm not. :-)
There is both SDL and some of SDL's helper libraries in the mix.
What I was saying mostly holds about the SDL helper libraries.
Turns out though that SDL has thread create & join options, so it can be
used multithreaded or single threaded. So it's more complicated.
We still though have the rub of do we have one or two SDL libraries/
modules, and then one or two of each of the helpers that needs to be
We will then face the same question for all libraries that may be used in
a threaded environment (and need to take actions if so) but may be used in
a non-threaded environment.
I think the sanest answer in the long run is to have only one.
Also note that what we're really doing is linking against a set of
routines that are both in libc and libpthread. Obviously only the
libpthread versions actually do anything real.