Re: g_spawn_async_with_pipes is not thread safe

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]