Re: gtk3 and fork/exec of non-gtk child

[Chris Vine <chris cvine freeserve co uk>]

On Sat, 14 Jan 2017 06:24:18 -1000 (HST)
rbd <rbd soest hawaii edu> wrote:
> Hi Emmanuele,
>
> Thank you for the suggestion! I have just now looked over the
> GSubprocess API. It appears to have the necessary functionality and
> would at first inspection integrate well with GUI main loop
> processing.
>
> However, I am still curious as to whether the
> fork/exec/SIGCHLDhandler model of my existing X11/Motif app will or
> will not work with gtk3. This design has worked quite well in this
> particular application for many years and I am reluctant to change it
> unless there is a strong argument that it either (i) no longer works
> as well as it did because of circumstances peculiar to gtk3 vs.
> X11/Motif or (ii) is likely to stop working in the near-to-medium
> future given current gtk3(/4?) development direction.
 
If you want to go by POSIX, then you can only call async-signal-safe
functions between the fork() and the exec().  Your code called
XtRemoveInput() and close().  close() is async-signal-safe.  I have no
idea whether XtRemoveInput() is, but I doubt it.

This rule would ordinarily preclude calling anything which might
allocate or free memory between fork() and exec() (none of those are
async-signal-safe), but glibc provides atfork handlers for the
allocator mutexes which actually makes that safe, and glib's g_spawn*
family rely on that.  But not all allocators are: Chromium's tcmalloc
allocator definitely is not, so you have problems if that gets linked
into your code.  Caveat forkor.

Just use the stuff glib provides, as suggested.

Chris