On Fri, 3 Jun 2016 12:30:04 +0100 Simon McVittie <simon.mcvit...@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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
