hi, On Sat, Mar 21, 2015, at 01:19, Jasper St. Pierre wrote: > 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 recommend using GSubprocess. g_subprocess_launcher_take_fd() lets you give an fd (along with a target_fd number). This fd will appear in the newly-spawned process as the "target" number you gave. This is what I mean by code that spawns processes having explicit control over what they do. For example: int sv[2]; socketpair (..., sv); g_subprocess_launcher_take_fd (launcher, sv[1], 3); g_subprocess_launcher_spawn (launcher, NULL, "/usr/bin/whatever"); will put the sv[1] end of the socket pair into the launched process as fd 3. > 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? I'm not sure. It probably depends on the outcome of this thread. I'm leaning towards "we won't do it if it complicates the code". Cheers _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
