tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: fixing libpthread noload, another approach

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

Home | Main Index | Thread Index | Old Index