This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Should glibc be fully reentrant? -- No. (Roland was right).
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Cc: Roland McGrath <roland at hack dot frob dot com>, Siddhesh Poyarekar <siddhesh at redhat dot com>
- Date: Thu, 11 Dec 2014 09:41:59 -0500
- Subject: Re: Should glibc be fully reentrant? -- No. (Roland was right).
- Authentication-results: sourceware.org; auth=none
- References: <5488F9C6 dot 9080605 at redhat dot com> <54898FE0 dot 8060701 at redhat dot com>
On 12/11/2014 07:36 AM, Florian Weimer wrote:
> On 12/11/2014 02:56 AM, Carlos O'Donell wrote:
>> After serious review it seems like we will need to start by saying
>> that an interposed malloc must operate as-if it were in
>> async-signal context and use only those functions which are marked
>> as async-signal-safe.
>
> Practically speaking, this seems rather restrictive. Most mallocs
> need locking, and implementations may want to use pthread mutexes.
> Those are not async-signal-safe, and I doubt they can be made
> reentrant, either.
>
> To clarify, I think the idea is fine, it's just the wording that
> needs fine-tuning.
To clarify though, I mean only to start at this extreme position
and then work my way towards a useful set of functions that could
be used by an interposed malloc.
My expectation is that we will need a "Reentrant-Safe" safety
annotation e.g. R-Safe, and mark functions with that. Then limit
an interposed malloc to using only those functions. Similarly
our internal APIs must carry similar safety notations.
Cheers,
Carlos.