Re: fixing libpthread noload, another approach

[manu%netbsd.org@localhost (Emmanuel Dreyfus)]

Martin Husemann <martin%duskware.de@localhost> wrote:

> My understanding is that basically everyone besides you would prefer to keep
> things exactly as they are now.

This is just because I have hit a regression with it and other people
here have not (yet).
 
> For every clean solution the first step would be to actually measure the
> libc overhead introduced by "real locking" for single threaded apps. Second
> step would be to discuss which hackish solution to use, if the first step
> shows a too high penalty.

However small, there will be a performance penatly if we implement bits
of mutex and condvars in libc stubs. I made the change to do it and I
can run measurement, but what do you want to mesure? The hit on
pthread_mutex_lock()? on malloc()? On something else?

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu%netbsd.org@localhost