Re: g_spawn

[Havoc Pennington <hp redhat com>]

Michael Meeks <michael ximian com> writes: 
> 	I appreciate that; but what is done in g_spawn is a pretty heinous
> thing to do to an application; I agree the situation with CLOEXEC sucks
> really badly in Unix - so much is clear, but poking around at file
> handles you don't own is pretty horrible IMHO and bug syscall thrash.
>

What does it actually break? In the 2 years or more it's been in GNOME
1 I don't think we have a single case of it breaking anything, and it
was put in because of several cases of stuff being broken due to
inherited descriptors.
 
> 	Looking at it, it intrigues me that GConf does an idle init, which
> appears to be uncontrollable as to whether it does or does not do the
> FD_CLOEXEC thing - and it's not quite clear to me what is intended by
> the:
> 
> 	G_SPAWN_LEAVE_DESCRIPTORS_OPEN
> 
> 	flag that is passed in (gconf-internals.c:2889) since it appears from
> an strace, that it does the FD_CLOEXEC sweep when activating gconfd -
> whereas the method docs might suggest that it shouldn't with that flag ?
> [ one would imagine that GConf would in fact want to do the FD_CLOEXEC
> thing ] ?

GConf uses LEAVE_DESCRIPTORS_OPEN but then has this function run in
the child:

static void
close_fd_func (gpointer data)
{
  int *pipes = data;
  
  gint open_max;
  gint i;
  
  open_max = sysconf (_SC_OPEN_MAX);
  for (i = 3; i < open_max; i++)
    {
      /* don't close our write pipe */
      if (i != pipes[1])
        set_cloexec (i);
    }
}

i.e. the LEAVE_DESCRIPTORS_OPEN is just to avoid closing the pipe.

Havoc