Re: fixing libpthread noload, another approach

[Matt Thomas <matt%3am-software.com@localhost>]

On Feb 3, 2013, at 2:46 PM, Martin Husemann wrote:

> On Sun, Feb 03, 2013 at 07:28:14AM +0100, Emmanuel Dreyfus wrote:
>> [..] For instance,
>> if a PAM module links against libgobject-2.0.so
> 
> You point out the real bug pretty prominently here, don't you?
> What is it using libgobject for? Can that be split out in a separate binary
> (i.e. to run UI configuration dialogs or whatever, but leave the real PAM
> module untainted)?
> 
> Your suggestion, overall, returns the state to something similar than we
> had before - random runtime failures. This is the same for Joerg's suggestion
> (fake libpthread). However, if we could find an value for the supposed
> runtime penalty in single threaded programs if libc would use real mutices
> (as Christos asked for), we could make real progress in this endlessly 
> repeating thread.

A possible alternative is have to an alterantive libpthread which just 
provides the pthread routines using the libc compat routines and a 
version of pthread_create that just returns failure.