Re: closing extra fd's in gnome_execute_*



On Mon, 11 Jan 1999, George wrote:

> On Mon, Jan 11, 1999 at 08:59:20AM -0500, Elliot Lee wrote:
> > The issue is not really gnome_execute_*(). It is Manish trying to do bad,
> > non-scalable hacks to work around bad bash brokenness ;-)
> 
> no ... he's trying to fix bad gnome_execute_* assumptions ... there
> is absolutely no reason that most things you ou exec should use other
> fd's, or expect other fd's open ... there are other problem then bash
> openness that are a problem, ... such as leaking fd's if the process
> stays up longer then the parent has the fdopen .... and not being able
> to reclaim space ... since the child will have that file open ... even
> though it doesn't care about it .... not closing the fd's is broken
> behaviour .... if you really need to open fd's, you can use the with_fd
> functions manish provided ...

Actually, Elliot is right.  I didn't like the hack to begin with since
UNIX semantics are to pass fd's when exec'ing.  Look at what all the
shells do. Without the CLOEXEC flag though, I thought it would be
atrocious for applications to have to close all the fd's themselves(If it
were even possible) so I decided to give applications the correct behavior
with as few source changes as possible.  If people like the closing fd's
thing though, I can put it back, we should take a vote, things seem pretty
even right now. The applications should set the FD_CLOEXEC flag on fd's
they don't want inherited. I didn't know that the FD_CLOEXEC thing existed
otherwise I would have never put in the changes to begin with.  Thanks for
the support though :).  Now, there are closing_fds version of things for
people who never launch apps with a desire to inherit fd's to use.  Well,
there will be _closing_fds things as soon as I check stuff in.

Also, should the gnome_client stuff set CLOEXEC on all the ICE fds by
default?  Do we ever want to inherit those on exec?  I don't think so.   
 
Manish Vachharajani               Some Haiku: A crash reduces
<mvachhar@vger.rutgers.edu>                   your expensive computer
                                              to a simple stone - Unknown



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]