Re: I'm done with O_CLOEXEC

[Christian Hergert <christian hergert me>]

On 03/20/2015 01:43 PM, Ryan Lortie wrote:
> karaj,
>
> For those unfamiliar with the issue: when a process is created on UNIX
> via naive fork() and exec(), the default is that the process will
> inherit all of the file descriptors of the parent.  This makes a lot of
> sense for stdin, stdout and stderr, but almost nothing else.
>
> This has been the cause of a lot of strange problems over the years.
> The typical example: a process will open a listener socket at some point
> and sometime later will call a library function that does a naive
> fork()/exec() of a helper process that hangs around past the lifetime of
> the original program.  When you try to restart the first program, the
> socket is still being held open by the helper and the new instance can't
> bind it again.
>
> There are two fixes to this problem.

[..snip..]

This makes me happy. I don't think I've actually seen any of this stuff 
handled right. Not to mention that close() itself is basically broken in 
multi-threaded scenarios on Linux (Linus says to basically "just not 
worry about it" if you get EINTR, which may or may not have succeeded, 
and then the FD entry taken by another thread).

What I would welcome, is a function that says "glib, close all FDs you 
know about or that you created". If all the libraries did that, at least 
it would be possible for applications to maybe, sorta, do the right 
thing. (That would push the synchronization responsibility during 
fork()/exec() to the application).

-- Christian