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: Samuel Thibault <samuel dot thibault at ens-lyon dot org>
- To: Rich Felker <dalias at libc dot org>
- Cc: Andreas Schwab <schwab at suse dot de>, libc-alpha at sourceware dot org
- Date: Mon, 24 Aug 2015 18:26:41 +0200
- 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> <20150824162250 dot GD32742 at brightrain dot aerifal dot cx>
Rich Felker, le Mon 24 Aug 2015 12:22:50 -0400, a écrit :
> 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?
That would be simpler, yes.
> (for programs doing dubious stuff to begin with)
It's usually not programs which call pthread_mutex, but libraries which
want to be thread-safe without actually bringing the libpthread
dependencye.
Samuel