Re: closing extra fd's in gnome_execute_*
- From: Manish Vachharajani <mvachhar vger rutgers edu>
- To: Edward A Carter <ecarter U Arizona EDU>
- cc: Elliot Lee <sopwith redhat com>, Martin Baulig <martin home-of-linux org>, gnome-list gnome org
- Subject: Re: closing extra fd's in gnome_execute_*
- Date: Mon, 11 Jan 1999 11:31:07 -0500 (EST)
On Mon, 11 Jan 1999, Edward A Carter wrote:
> > Which, combined with some stupid bash stuff and a very large number of
> > fd's > 30 or so, cause runs of configure scripts to crash :). Please let
> > me know if you think my committed code is an acceptable compromise.
> So, why not just fix bash? Just closing all file descriptors without
> necessarily having any idea why they're open sounds like a horrible kludge
> that will someday come back to bite all of us in the ass...
Well, we should fix bash too. But as I said, so many programs have this
brokeness in them it isn't practical to fix them all. Besides, we should
close all the fd's anyway since that is the behavior that most programs
really want. The fd's are just closed in the forked child that will be
execed, not in the callers process. I added functions that won't close
the fd's as well in case some programs need this behavior.
Consider this. I am running program foo. foo opens a 30 megabyte file.
While the file is open it runs gnome_execute_async, say for the
help-browser or something. Now my disk runs out of space, so I rm the 30
meg file after quitting application foo. Unfortunately, I won't regain
that space until I close the help-browser. If foo happens to start many
programs, I have to quit them all before the space will be freed. This
will definitely bite us in the ass as well. We really should close the
fd's unless we want other behavior.
Manish Vachharajani Some Haiku: A crash reduces
<firstname.lastname@example.org> your expensive computer
to a simple stone - Unknown
] [Thread Prev