Re: [PATCH] libpthread NOLOAD removal

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

On Mon, Feb 18, 2013 at 08:45:19PM +0100, Joerg Sonnenberger wrote:
> On Sun, Feb 17, 2013 at 04:54:53AM +0100, Emmanuel Dreyfus wrote:
> > Here is my llatest patch for libpthread NOLOAD removal. It implements
> > minimal mutex, condvar and rwlock operations in libc thread stubs, so
> > that theses objects can be handled by both libc and libpthread after
> > libpthread has been loaded by dlopen.
> 
> It is still the wrong approach. Attached is a preliminary patch for
> devel/glib2 to fix the pthread usage. Primary issue with the patch is
> testing on other platforms and moving the condattr support into libc to
> complement the existing CV logic. It should also be decided whether we
> shouldn't just provide pthread_join and pthread_detach in libc.

I had an interesting idea (or evil thought).

Until pthread_create() is called, a process can only have one thread
so all the mutex/condvar function are almost no-ops (certainly they
don't need to do any locked bus operations).

So calling pthread_create() could set a global flag that enables the
slower locked path through the the mutex/condvar code.

Unfortunately testing the flag involves code - and is probably a
measurable performance drop (even if the static prediction is set
for not-threaded).

However the functions are already indirect calls (through the PLT),
so the following ought to be possible (for each relevant function).

1) Have a function that actually tests the global data, make this be
   the one that dlsym() finds and the dynamic loader will use.
   And any program that does f_ptr = &mutex_enter();

2) Add a function to the dynamic loader to allow code to modify the
   PLT entry for a function to reference a different label.

3) At startup use (2) to make the convar/mutex function PLT entries
   reference the 'fast' verions.

4) When ptherad_open() is called use (2) to change the PLT entries
   to reference the 'slow' versions.

Which code is in libc and which in libpthead then doesn't really matter
(in the sense that it could all be in libc).

Hmmm... I wonder how much code out there creates a mutex+convar in
order to wait for an absolute time?
(And who's bright idea was it to only allow waiting for an absolute
time anyway).

        David

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