Web lists-archives.com

Re: g_spawn_async_with_pipes is not thread safe




On 06/ 3/16 08:31 AM, Chris Vine wrote:
On Fri, 3 Jun 2016 12:30:04 +0100
Simon McVittie <simon.mcvittie@xxxxxxxxxxxxxxx> wrote:
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.)

I'd like to think Solaris still counts - certainly we're trying to support
modern glib & gtk3 applications in Solaris 12.   We do have closefrom()
though ours isn't documented as async-signal-safe or MT-safe.

I've wondered before how hard it would be to wrap the g_spawn* functions
around the posix_spawn API's we prefer, but have been too busy getting
our packages updated to more current versions to work on that.  We do
have a MT-safe posix_spawn_file_actions_addclosefrom_np() in libc we
could then use.

--
	-Alan Coopersmith-              alan.coopersmith@xxxxxxxxxx
	 Oracle Solaris Engineering - http://blogs.oracle.com/alanc
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gtk-devel-list