This is the mail archive of the
mailing list for the glibc project.
Should glibc be fully reentrant? -- No. (Roland was right).
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: 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: Wed, 10 Dec 2014 20:56:22 -0500
- Subject: Should glibc be fully reentrant? -- No. (Roland was right).
- Authentication-results: sourceware.org; auth=none
In  I pose the question: Should glibc be fully reentrant?
In that email I write:
It is my opinion that users expect to be able to call any
routine in the runtime without caution unless we tell them
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.
A blanket statement saying that an interposing malloc should
be able to do what it wants is a bad idea. Roland was right.
Serious review has shown that so many interfaces are non-reentrant
that a user malloc implementation has be exceedingly simple and
avoid most glibc functions (particularly those dealing with nss
or identity) that it's simpler to just document that a user
provided malloc must basically operate in async-signal-safe context.
The glibc malloc breaks this rule, but in doing so spawns a large
class of bugs arround the MALLOC_CHECK_ behaviour. Here malloc
may, depending on the architecture, calls backtrace, dlopen, use
IO streams, etc, all which usually result in recursive failures
or deadlocks. Siddhesh and I have a simple plan for fixing this,
but that's off-topic.
Start by documenting that user provided malloc will only be
supported if it uses only async-signal-safe functions, or functions
documented as being reentrant.
I will work on extending the list of reentrant functions as required
and on a per-function basis, starting with dlopen to allow some
rudimentary support for loading a shared library that itself might
contain async-signal-safe or reentrant functions.