Re: RFA: close-on-exec internal file descriptors

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> From: Tom Tromey <tromey@redhat.com>
> Date: Sat, 06 Dec 2008 15:05:49 -0700
> 
> >>>>> "Mark" == Mark Kettenis <mark.kettenis@xs4all.nl> writes:
> 
> Tom> I chose to take advantage of the new glibc flags like O_CLOEXEC when
> Tom> they are available.  This is friendlier in the Python case -- here,
> Tom> gdb might have multiple threads, and the glibc flags enable us to
> TOM> avoid a window where a file descriptor is not marked close-on-exec.
> 
> Mark> Sorry, but I don't see the point in having #ifdef O_CLOEXEC code
> Mark> when there is a perfectly portable way to do this using fcntl.
> 
> It is better for thread safety.  This matters in the Python case.

Hmm, but that'd mean there will be thread-safety problems on platforms
that don't have O_CLOEXEC (including older Linux systems).  That's not
good :(.

Note that my suggestion to explicitly close file descriptors between
fork() and exec() doesn't have thread-safety problems.

> Mark> I also think it would actually be better to explicitly close file
> Mark> descriptors before doing an exec instead of relying on people to use
> Mark> the proper _cloexec call throughout gdb.
> 
> Why do you think this?
> 
> I think that it is difficult to truly ensure reliability with either
> approach.  We might miss an open, but so too we might miss a
> fork/exec.  The more libraries we use, the more likely this becomes.

I think open is used quite a bit more than fork/exec.  And libraries
that use fork/exec are rare.

> But, since gdb and all its dependencies are free software, I think we
> might as well try to implement the better approach, whichever that is.
> In my view, close-on-exec is preferable.  It better communicates the
> intent of the programmer, and in the library case it is an abstraction
> barrier.

Sorry, but I fail to understand what you mean with "abstraction barrier".