Hi; On 14 January 2017 at 17:17, infirit <infi...@gmail.com> wrote: > Op 01/14/2017 om 06:05 PM schreef Emmanuele Bassi: >>> 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're not calling any GTK/GDK/X11 functionality in the children, >> then you don't need to do anything special after forking. This has >> been true for years, and will remain true for the foreseeable future. >> The only thing you have to worry about are the usual interactions >> between forking and system calls like malloc, or threading primitives. > > There is an example [1] under python that demonstrates why this is a > problem quite well. Hope this helps.
That blog post is from 7 years ago. GLib does not require thread initialization, and in general it uses O_CLOEXEC for every file descriptor it creates. Of course, this can only happen on systems with O_CLOEXEC, and it won't save you from things that happen at the Python level - but at least GLib should be a more considerate citizen, these days. The known issues with malloc() and threads, though, still remain because GLib cannot work around those. Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
