Re: I'm done with O_CLOEXEC

["Jasper St. Pierre" <jstpierre mecheye net>]

Sorry, I'm not overly familiar with this sort of stuff.

Right now, we use raw fork/exec in mutter where we need to do some tricky management and explicitly leak an FD into the correct place [0]. Does this mean that from now on, glib might leak an FD and we need to be prepared to handle that? Refactoring the code to use a child setup func and using g_spawn isn't quite really what I want to do (can I even leak an FD made with socketpair through in that case?), but I want to be aware of what might break in the future, and whose bug it should be.

I know it's difficult to set a policy about this, but is there anything I can do to prevent too much damage in the future? If I file a patch against glib for where it might not set CLOEXEC with an easy flag the syscall, will you accept it, or are you going to reject it to stop me from relying on CLOEXEC?

[0] https://git.gnome.org/browse/mutter/tree/src/wayland/meta-xwayland.c#n458

On Fri, Mar 20, 2015 at 10:10 PM, Ryan Lortie <desrt desrt ca> wrote:

On Fri, Mar 20, 2015, at 23:33, Matthias Clasen wrote:
> So,  you found that dup3 doesn't do what you want, and now you want to
> throw out the baby with the bathwater and just say "I don't care
> anymore if we leak fds" ?

dup3() was a bit of a "straw that broke the camel's back" case.  I could
point at the existence of g_unix_open_pipe() as a similarly ridiculous
case, or many others.

I'm also not impressed by the inaccurate categorisation.  I thought I
explained fairly clearly why I believe that leaked fds will _not_ be the
case, even without O_CLOEXEC.

I was looking for some slightly more constructive arguments...

Cheers
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list gnome org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

--

  Jasper