Subject: Re: libpthread busted?
To: Peter Seebach <firstname.lastname@example.org>
From: Nathan J. Williams <email@example.com>
Date: 03/04/2003 22:46:43
"Nathan J. Williams" <firstname.lastname@example.org> writes:
> The right thing here is for libc to export its thread-operation
> stubs as pthread functions, and then to make SDL-image and similar
> libraries not link directly against libpthread, but let the libc stubs
> satisfy their mutex-locking needs until and unles the library is
> linked into a threaded application. This prevents pulling
> libpthread.so into unwary applications, which as you've seen, has all
> sorts of failure modes.
> Or, to put it another way, you should wait until we fix this :) I'll
> have a go at it over the weekend and should be able to have something
> done by Monday.
Okay, it's Tuesday and I don't have a good fix for this yet. Let me
explain where I am.
1) The SDL library, among its other features, presents applications
with a "portable" wrapper around a few simple thread operations
(create/join, mutex lock/unlock, condvar wait/signal). On NetBSD
it is using libpthread as the backend for these operations. This
means that SDL-using applications need to have libpthread linked
in, explicitly or implicitly. The SDL shared library object does
not have a recorded dependance on libpthread.so, so applications
need to be explicit.
2) The sdl-config script tells SDL-using applications what compiler
and linker flags to use to get SDL. At the moment, it includes
-lpthread. However, library extensions to SDL, like SDL-image,
also use sdl-config and as a result the shared objects end up with
recorded dependancies on libpthread.so.
3) p5-SDL is a bunch of glue between Perl and some of the SDL
interfaces. Notably, though, it doesn't expose SDL's thread
features. This more-or-less makes sense, as I understand it,
because Perl has its own (optional, currently disabled) thread
layer, and threading behind the back of the Perl interpreter
you're glued into is probably a bad idea. However, because of
point (2), libpthread.so gets pulled in, even though it's not
going to be used at all.
4) Since perl uses dlopen() to get at SDL_perl.so, it dynamicaly
activates libpthread, which leads to the previously mentioned
lossage inside the libc thread stubs. "boom".
I think the right point of attack is (2). Random SDL add-on objects
shouldn't need libpthread linkage.
The best way to accomplish this would be to tweak the build systems so
that the random add-ons get a different set of libraries from
sdl-config. I'm not sure how feasable this is; I'd rather be
compatible with the rest of the world and not force us to keep a lot
of local patches to the build systems of all these weird libraries.
The second-best approach would be to make SDL itself not build against
libpthread at all but use libc stubs... although this would have to
include functions like pthread_create() that would have to fail as a
stub routine. This would mean that we would have to adjust the build
system of SDL-using *applications* to explicitly add -pthread or
-lpthread in order to successfully run if they actually use the thread
interface of SDL. This is a little worrisome because failing to link
against libpthread would produce a run-time error (assertion in libc
pthread_create() stub) rather than a link-time error.