Re: g_spawn_async_with_pipes is not thread safe

[Chris Vine <chris cvine freeserve co uk>]

On Fri, 3 Jun 2016 12:30:04 +0100
Simon McVittie <simon mcvittie collabora co uk> wrote:
> 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  

Actually I didn't really write that.  I merely cited glib's own
documentation, while pointing out that it was in part wrong.
 
> 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().

For the g_spawn* family of functions, glib has in effect adopted (on
linux platforms) an unspoken glibc dependency.  I do not know what the
position is on windows and solaris.  (Possibly solaris doesn't count
any more.)

If you are worried about it the simple answer is not to use the
g_spawn* functions on unsupported platforms or unsupported libc's.
It is perfectly possible to comply with POSIX requirements when
fork()ing in a multi-threaded program using the native APIs.  The
documentation could certainly do with improvement though.

Chris