- From: Michael Meeks <michael ximian com>
- To: Havoc Pennington <hp redhat 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: 26 Mar 2002 09:52:14 +0000
On Mon, 2002-03-25 at 16:52, Havoc Pennington wrote:
> The point is, if you've thought about this problem then you can easily
> make g_spawn do the efficient thing, but if you haven't thought about
> it then g_spawn defaults to something safe. Think of
> G_SPAWN_DO_NOT_CLOSE_DESCRIPTORS as
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.
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 ] ?
mmeeks gnu org <><, Pseudo Engineer, itinerant idiot
] [Thread Prev