This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Dummy pthread functions in libc considered harmful
- From: Rich Felker <dalias at libc dot org>
- To: Samuel Thibault <samuel dot thibault at ens-lyon dot org>
- Cc: Andreas Schwab <schwab at suse dot de>, libc-alpha at sourceware dot org
- Date: Mon, 24 Aug 2015 12:22:50 -0400
- Subject: Re: Dummy pthread functions in libc considered harmful
- Authentication-results: sourceware.org; auth=none
- References: <mvmr3ms4sbj dot fsf at hawking dot suse dot de> <20150824153816 dot GC3210 at type dot bordeaux dot inria dot fr>
On Mon, Aug 24, 2015 at 05:38:16PM +0200, Samuel Thibault wrote:
> Andreas Schwab, le Mon 24 Aug 2015 17:30:40 +0200, a Ãcrit :
> > BZ #18853 shows how the use of the dummy pthread functions in libc can
> > be harmful if dlopen brings in libpthread by dependency.
>
> I have to admit I've always wondered about this case, and never took
> the time to report the issue, partly because I guessed people wouldn't
> dlopen() while "owning" a mutex. This can be fixed by making the mutex
> stubs really modify the mutex, possibly optimized into just not using
> lock prefixes etc.
>
> Not having proper stubs in libc makes applications write their own stubs
> (see libpthread-stubs in freedesktop for instance), which will suffer
> from the same issue.
I agree that removing them would be a bad idea, but why not just put
the actual code (real locking) in the ones in libc.so? The tiny
performance gains (for programs doing dubious stuff to begin with)
from omitting the lock prefix seem like they would be dwarfed by the
maintenance cost of having to provide a separate version of the code
and the risk of bugs from possibly invoking the wrong version of the
function invoked (e.g. if a non-threaded program is using a
process-shared mutex, where it would _seem_ to work but lack proper
synchronization).
Rich