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 02:33 PM, OndÅej BÃlka wrote:
On Thu, Dec 11, 2014 at 01:36:48PM +0100, 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.

No, making them reentrant is relatively simple as I wrote before, just
wrap calls in something

static __thread int recursed
if (recursed)
   return allocate_by_mmap();

I meant the locking functions.

Anyway, the above needs a volatile specifier somewhere, and even then, it might still be outside of what can be expressed in C.

Florian Weimer / Red Hat Product Security

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