This is the mail archive of the libc-alpha@sourceware.org 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 Thu, Dec 11, 2014 at 02:50:18PM +0100, Florian Weimer wrote:
> 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();
> >else
> >   {
> >     recursed=1;
> >     normal;
> >     recursed=0;
> >   }
> 
> 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.
>
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.


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