Re: g_spawn_async_with_pipes is not thread safe

[Simon McVittie <simon mcvittie collabora co uk>]

On 03/06/16 09:18, Chris Vine wrote:
> POSIX allows only async-signal-safe functions (see signal(7)) to be
> called in the child between fork() and exec(), which drastically limits
> the usefulness of child setup functions

There's a gap here between the theory (GLib mostly has only POSIX
requirements) and the practice (glibc malloc is designed to allow things
POSIX doesn't, and this useful functionality would be difficult to
achieve without that). In principle GLib could call opendir() on
/proc/$pid before forking, then read it in the child, but readdir()
isn't async-signal-safe either. Doing the reading in the parent isn't a
solution, because the parent is potentially multi-threaded, so it could
be opening and closing file descriptors in other threads (racing with
the readdir()).

In principle the parent could read the new child's fd table and write a
list of fds into a pipe, for the child to close them all or set them all
close-on-exec, while the child waits for EOF on that pipe before
proceeding with the close and exec operations... but that seems fairly
horrible.

I think what we really want here is *BSD closefrom(), which at least
FreeBSD documents as async-signal-safe. Unfortunately, Linux doesn't
have that system call. libdbus would have the same issue on platforms
that don't have closefrom().

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>