hi, On Sat, Mar 21, 2015, at 01:59, Jürg Billeter wrote: > 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.
This is probably the best counter-argument so far: since we all agree that the inherit-by-default behaviour is silly, we should try as much as possible to mitigate it. I agree with that point, but the main thrust of the argument that I was trying to make originally (and somewhat detracted from with my ranting) is: - there is often a high price to pay for "doing the right thing"; and - it's not actually necessary Sure, it's conceivable (and even likely) that there is code that isn't up to snuff, but that's sort of the point of this thread. I want to shift responsibility for "getting this right" from the innumerably many places that we create fds to the very few places that we launch subprocesses. And by the way: the "high price" that we pay is not just in cases where we need to implement one codepath for Linux and a fallback for other platforms inside of GLib. If you fully buy into the O_CLOEXEC mantra, then it means that every single person who casually calls open() (even in application code) needs to take care to get it right, for fear that some naive library is doing fork()/exec() in another thread. Cheers _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list