Should glibc be fully reentrant? -- No. (Roland was right).

["Carlos O'Donell" <carlos at redhat dot com>]

In [1] 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
otherwise.
~~~

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.

In summary:
===========

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.

Cheers,
Carlos.

[1] https://sourceware.org/ml/libc-alpha/2014-10/msg00492.html