This is the mail archive of the 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: Should glibc be fully reentrant? -- No. (Roland was right).

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.


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