This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Should glibc be fully reentrant? What do we allow interposed symbols to do?
- From: Torvald Riegel <triegel at redhat dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: Roland McGrath <roland at hack dot frob dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 24 Oct 2014 11:31:32 +0200
- Subject: Re: Should glibc be fully reentrant? What do we allow interposed symbols to do?
- Authentication-results: sourceware.org; auth=none
- References: <54456FA1 dot 9070804 at redhat dot com> <20141020204153 dot 83C542C3B0D at topped-with-meat dot com> <54457C4C dot 4080307 at redhat dot com> <20141021224739 dot 080382C3AB2 at topped-with-meat dot com> <54486800 dot 4040806 at redhat dot com>
On Wed, 2014-10-22 at 22:29 -0400, Carlos O'Donell wrote:
> On 10/21/2014 06:47 PM, Roland McGrath wrote:
> > But the slippery slope concerns me most of all.
>
> Any function the user interposes acts as a synchronous interrupt on the
> runtime.
Note that is simpler because we have no parallelism in glibc right now.
And we may never have a need for this because we don't do big chunks of
work, but it's worth considering, I think. Once you go parallel,
"synchronous interrupt" constricts the implementation to a larger degree
than when this applies just to a single thread that doesn't change.
> It is my opinion that users expect to be able to call any routine in the
> runtime without caution unless we tell them otherwise.
>
> Given that dlopen locks are recursive, as are stdio locks, I propose we
> fully support this notion that users already believe exists.
Well, what this tells us is that these two things do not disallow
reentrancy on all the resources they protect with locks. But that
doesn't quite tell us that they can deal with reentrancy in all
situations, right?
> The alternative is that we don't support it and treat interposed functions
> as if they were in a signal handler context, only being allowed to call
> async-signal-safe functions, and we might as well remove the recursive
> support from the locks such that users get useful backtraces from deadlocks.
> It is my opinion that such a direction would not help our users and would
> not help the project.
>
> The similar situations we need to clarify are LD_AUDIT modules, and
> IFUNC resolvers, but let us proceed orderly one topic at a time.
>
> In summary
> ==========
>
> Allow interposed functions to call back into the runtime, and fix any
> places where this breaks.
As worded, I do not agree. IMHO, this should be opt-in. It may very
well be that we'd want an opt-in for large sets of functionality, but
I'd be concerned about promising support for this *in general*.