This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Should glibc be fully reentrant? -- No. (Roland was right).
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: Carlos O'Donell <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Roland McGrath <roland at hack dot frob dot com>, Siddhesh Poyarekar <siddhesh at redhat dot com>
- Date: Sun, 21 Dec 2014 15:42:23 +0100
- Subject: Re: Should glibc be fully reentrant? -- No. (Roland was right).
- Authentication-results: sourceware.org; auth=none
- References: <5488F9C6 dot 9080605 at redhat dot com> <54898FE0 dot 8060701 at redhat dot com> <20141211133353 dot GB10717 at domone> <5489A11A dot 3080300 at redhat dot com> <20141211141136 dot GA17090 at domone> <548ABA5B dot 9090002 at redhat dot com> <20141212161750 dot GA22945 at domone> <548EA164 dot 5040004 at redhat dot com>
On Mon, Dec 15, 2014 at 09:52:52AM +0100, Florian Weimer wrote:
> On 12/12/2014 05:17 PM, OndÅej BÃlka wrote:
> >On Fri, Dec 12, 2014 at 10:50:19AM +0100, Florian Weimer wrote:
> >>On 12/11/2014 03:11 PM, OndÅej BÃlka wrote:
> >>
> >>>Yes, I wrote that from head so I forgot volatile/asm barrier. One could
> >>>add requirement like needs to be compiled by gcc4-6+ instead pure C as
> >>>just using signals is not part of C standard.
> >>
> >>GCC emulates atomics with locks on some platforms, or some lock-free
> >>instruction sequences may not be reentrant. This begins to look
> >>like a can of worms, unfortunately.
> >>
> >It uses only thread local variable. If they are not reentrant its
> >gigantic hole, you could not for example use sigaction as it could
> >set errno which is thread local variable.
>
> Sorry, what I'm trying to say is that atomics are not specified as
> async-signal-safe, and some actually aren't in practice.
>
You do not have to create perfect solution, most programmers would not
care if we provided reentrancy on all architectures but sparc.
A malloc example that I wrote earlier is not perfect but would solve most
reports in bugzilla and would be enough in cases where it was infinite
recursion without signal.
For reliable solution I would need a bigger hammer, user would need to
compile say with -DSIGNAL_SAFE and add calls signal_start(), signal_end()
to all signal handlers. That could be relaxed when we add these wrappers
automatically, to requiring signal_end() before user does longjmp from
signal.
Then malloc will just call mmap and avoid any atomic in signal.
Similar trick works with IO output functions, in signal copy arguments
to mmaped array and print these next time IO is called in normal
content.