On Sat, 21 Mar 2015 06:59:41 +0100 Jürg Billeter <j...@bitron.ch> wrote: > On Sat, 2015-03-21 at 01:32 -0400, Ryan Lortie wrote: > > It seems that this is a (slightly) recent addition. It's > > documented: > > > > F_DUPFD_CLOEXEC (int; since Linux 2.6.24) > > > > so I'm sure we'll probably still need to write an ifdef with a > > fallback... > > If you're referring to older Linux versions, I disagree. Even glibc > has dropped support for Linux < 2.6.32, ifdef may be needed for other > kernels, though, not sure. > > > The wider question about the usefulness of O_CLOEXEC still stands. > > I would keep using O_CLOEXEC as it's as close as we can get to the > behavior that should have been the default: don't implicitly inherit > file descriptors on exec. > > Maybe there are applications out there that rely on correct file > descriptor flags and directly call fork/exec. You could try to > convince them to switch to GSubprocess (or work around the issue in > their own fork/exec code). However, as I think we all agree that > O_CLOEXEC is the best default behavior, I don't see why we should > break these applications.
Further, there are cases where porting to GSubprocess does not actually do the job easily because (as I understand it) GSubprocessFlags can be set to either close all descriptors on exec other than those for stdin, stdout and stderr, or not close any descriptors on exec. I have code which uses glib and also launches a helper child process using fork/exec so that the helper process can run a VM with garbage collection, for a particular purpose not relevant here. The parent and helper processes communicate via two pipes, which for various reasons do not dup stdin and stdout on the helper process but act as independent channels. This means that the helper process's descriptors for the pipes must be kept open on exec. At present the code relies on glib doing the right thing and looking after its own descriptors on exec. It would be a nuisance if that could not be relied on in the future, which I think is your proposal. (I understand your point that that is not an assumption that users should be entitled to make, but it IS the present behaviour and changing it in a stable series may introduce breakage.) However, if that is the proposal and you are going to go ahead with it, can you provide a "close_all_except" convenience function to go along with it which will walk open descriptors and close them but allow the user to supply a list of user's descriptors which are not to be closed, which the user can call between the fork and the exec, if that can be done without calling async-signal-safe functions (however, possibly walking the open descriptor list cannot be done using only async-signal-safe functions, which would make it a non-runner for multi-threaded programs). Obviously the user could do that herself, but at some inconvenience for code intended to run on a number of platforms, some of which may have fdwalk() and some of which may not, and for some of which fdwalk() may be async-signal-safe and some of which may not. Chris _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
