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

[Emmanuele Bassi <ebassi gmail com>]

Hi;

On 14 January 2017 at 17:17, infirit <infirit 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]