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: OndÅej BÃlka <neleai at seznam dot cz>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: Andreas Schwab <schwab at suse dot de>, Carlos O'Donell <carlos at redhat dot com>, Samuel Thibault <samuel dot thibault at ens-lyon dot org>, Rich Felker <dalias at libc dot org>, libc-alpha at sourceware dot org
- Date: Mon, 7 Sep 2015 16:21:01 +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> <20150824162641 dot GH3210 at type dot bordeaux dot inria dot fr> <mvmbndv4zeh dot fsf at hawking dot suse dot de> <55DC1700 dot 6060905 at redhat dot com> <55E74931 dot 3070509 at redhat dot com> <mvm613st1o9 dot fsf at hawking dot suse dot de> <20150903184536 dot GA7182 at domone> <55ED755C dot 8030404 at redhat dot com>
On Mon, Sep 07, 2015 at 01:30:36PM +0200, Florian Weimer wrote:
> On 09/03/2015 08:45 PM, OndÅej BÃlka wrote:
> > On Thu, Sep 03, 2015 at 09:14:14AM +0200, Andreas Schwab wrote:
> >> "Carlos O'Donell" <carlos@redhat.com> writes:
> >>
> >>> Is there ever a safe way to transition from running unthreaded to
> >>> threaded if you are not using a full implementation of locks in libc.so?
> >>
> >> As long as you have no "locked" mutexes while libpthread is being loaded
> >> (which installs the real pthread_mutex functions), there is no danger,
> >> since you cannot create new threads without libpthread being fully
> >> active.
> >>
> > A requirement for no locked mutex isn't necessary. It simplifies things
> > as with it a functions could be nop.
>
> No-op locks aren't possible if you want to support lock upgrades with a
> delayed loading of libpthread. You either need to keep them consistent
> with future libpthread usage all the time (without using atomics), or
> keep them in some sort of data structure so that you can find them at
> libpthread loading time to switch them to a libpthread-supported state.
>
I wrote about that in original mail below that quote.