- From: Havoc Pennington <hp redhat com>
- To: Michael Meeks <michael ximian com>
- Cc: Bradford Hovinen <hovinen ximian com>, Jacob Berkman <jacob ximian com>, desktop-devel-list <desktop-devel-list gnome org>
- Subject: Re: g_spawn
- Date: 27 Mar 2002 22:47:08 -0500
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
> 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
> 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
close_fd_func (gpointer data)
int *pipes = data;
open_max = sysconf (_SC_OPEN_MAX);
for (i = 3; i < open_max; i++)
/* don't close our write pipe */
if (i != pipes)
i.e. the LEAVE_DESCRIPTORS_OPEN is just to avoid closing the pipe.
] [Thread Prev