Re: g_spawn_async_with_pipes is not thread safe
- Date: Fri, 3 Jun 2016 16:31:59 +0100
- From: Chris Vine <chris@xxxxxxxxxxxxxxxxxxxxx>
- Subject: Re: g_spawn_async_with_pipes is not thread safe
On Fri, 3 Jun 2016 12:30:04 +0100
Simon McVittie <simon.mcvittie@xxxxxxxxxxxxxxx> 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
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.
gtk-devel-list mailing list