This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: [libvirt] [PATCH 3/3] virCommand: use procfs to learn opened FDs
- From: Florian Weimer <fweimer at redhat dot com>
- To: Eric Blake <eblake at redhat dot com>
- Cc: Michal Prívozník <mprivozn at redhat dot com>, libvir-list at redhat dot com, libc-help at sourceware dot org
- Date: Mon, 15 Jul 2019 16:26:47 +0200
- Subject: Re: [libvirt] [PATCH 3/3] virCommand: use procfs to learn opened FDs
- References: <cover.1562138162.git.mprivozn@redhat.com> <8cf311e297b18b159d3bb6dc201df260585b904c.1562138162.git.mprivozn@redhat.com> <0f316f41-225a-23b4-e923-46edef6576dc@redhat.com> <72d0d244-0d7f-3015-056e-c86298d37974@redhat.com> <7b2ada48-1d2a-98fa-d954-c2685b0e4059@redhat.com> <87blxx6vgh.fsf@mid.deneb.enyo.de> <cf7eda74-7cfa-16ee-7161-feea8604e799@redhat.com>
* Eric Blake:
> On 7/14/19 12:23 AM, Florian Weimer wrote:
>> * Eric Blake:
>>
>>> Does anyone know if glibc guarantees that opendir/readdir in between
>>> multi-threaded fork() and exec() is safe, even though POSIX does not
>>> guarantee that safety in general?
>>
>> glibc supports malloc after multi-threaded fork as an extension (or as
>> a bug, because it makes malloc not async-signal-safe).
>
> It's not a bug for glibc to provide guarantees above what POSIX
> requires, but IS a bug for applications to depend on those guarantees
> without realizing they are non-portable.
It's a bug because it makes malloc not async-signal-safe (as required by
POSIX) in our current implementation of malloc.