Web lists-archives.com

Re: I'm done with O_CLOEXEC




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
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gtk-devel-list