Re: I'm done with O_CLOEXEC
- Date: Fri, 20 Mar 2015 17:29:29 -0700
- From: Christian Hergert <christian@xxxxxxxxxx>
- Subject: Re: I'm done with O_CLOEXEC
On 03/20/2015 01:43 PM, Ryan Lortie wrote:
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.
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).
gtk-devel-list mailing list