Re: pam-saml/cy2-saml -lpthread and NetBSD 6.0

[David Laight <david%l8s.co.uk@localhost>]

On Sat, Jan 19, 2013 at 09:38:43PM +0100, Emmanuel Dreyfus wrote:
> Christos Zoulas <christos%astron.com@localhost> wrote:
> 
> > >5) Put the mutex/condvar code into libc, if libpthread isn't loaded
> > >   use versions that do unlocked accesses and can't fail.
> > 
> > 5 is the way to go I think.
> 
> That means that dlopen() would ignore libpthread.so and carry on,
> instead of considering it fatal and return an error?  That would solve a
> lot of problems, IMO.

You missed the point - the idea would be allow libpthread to be loaded later,
and for later libraries to use threads.

A non threaded program can only be inside dlopen() at the time libpthread
is loaded - so I suspect the only mutex it might be holding are those
inside the dynamic loader itself.

It might even be true that, provided the mutex/condvar initialisers work
the functions can be no ops until libpthread is loaded.

I suspect there is some reason why that isn't true.

Which bits of libc actually acquire mutex?
I can think of malloc(), putenv(), atexit() - probably a few others.
malloc() is probably the only one where you care - and somthing to
trap malloc() calls from signal handlers might be useful.

        David

-- 
David Laight: david%l8s.co.uk@localhost