On Sat, 14 Jan 2017 06:24:18 -1000 (HST) rbd <r...@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 _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
