Thanks. I have refactored this code to use GSubprocess: https://git.gnome.org/browse/mutter/commit/?id=d4e8d97e58f9c931a14ea9b6484890d7a66e65e7
Not overly happy with the hardcoded fd assignments, but it's not the end of the world. On Fri, Mar 20, 2015 at 10:28 PM, Ryan Lortie <de...@desrt.ca> wrote: > 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 -- Jasper _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
