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
thread-savy.

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.

Take care,

Bill