This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Dummy pthread functions in libc considered harmful


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]