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

[rbd <rbd soest hawaii edu>]

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.

Thanks again!

Roger

On Sat, 14 Jan 2017, Emmanuele Bassi wrote:

> Hi;
>
> Don't use fork()/exec() directly with manual signal connection; use
> GSubprocess from GIO, instead, which is a much better API, it's safe, and
> it's likely more comprehensive in handling additional cases.
>
> Ciao,
>  Emmanuele.
>
> On Sat, 14 Jan 2017 at 01:30, rbd <rbd soest hawaii edu> wrote:
>
>
>       Hi all,
>
>
>
>       I have a few questions relating to the use of fork/exec within a
>       gtk3
>
>       program. Briefly, (i) can this be made to work at all, and (ii)
>       should I
>
>       perform any specific operations related to disconnecting from
>       gtk within
>
>       the child process code of my gtk parent in the very brief
>       interval between
>
>       the fork() and the exec()? Following are details of my situation
>       which I
>
>       believe is extremely simple, and I want to use the very simplest
>       working
>
>       solution.
>
>
>
>       I am porting someone else's old X11/Motif process management GUI
>       to gtk3.
>
>       It makes extensive use of fork/exec and a SIGCHLD signal handler
>       (which
>
>       waitpid(.. WNOHANG)s on terminated children) to manage somewhere
>       between 5
>
>       and 20 or so child processes. These children do NOT have any GUI
>       and are
>
>       background data logging processes which read serial and/or
>       network data
>
>       sources and write reformatted output to serial, network and/or
>       disk
>
>       destinations. The management GUI is a simple tabular display
>       with one row
>
>       per child that shows whether each child is running or not and
>       has a
>
>       clickable button allowing the operator to start/stop/restart
>       that
>
>       particular child. The manager needs to remain running for time
>       periods as
>
>       long as 3 months.
>
>
>
>       Porting this to gtk3 seemed trivial until I started reading
>       these archives
>
>       yesterday and encountered numerous warnings about using
>       fork/exec with
>
>       gtk. It's unclear whether or not they apply to me since my child
>       processes
>
>       will have absolutely no GUI of any kind (not gtk, X11 or
>       anything else)
>
>       either related to or even completely independent of the gtk GUI
>       running in
>
>       the manager process. Opinion about this does not seem to be
>       uniform: some
>
>       people say that fork/exec works just fine if you have a simple
>       scenario,
>
>       others give dire warnings and recommend more complicated systems
>       of forks
>
>       within threads, use of various glib spawn/task functions, etc. I
>       do not
>
>       want to (i) expend more effort than is truly needed, or (ii)
>       unnecessarily
>
>       burden the code with complexity specific to the needs of
>       gtk/glib that
>
>       will all have to be unraveled and redone ten years from now when
>       the
>
>       inevitable next-generation API displaces gtk. (No offense
>       intended, but
>
>       I've seen this movie a few times. ;-> )
>
>
>
>       Following is the existing fork-to-exec segment of the child code
>       in the
>
>       X11/Motif manager. Only a couple things of interest take place
>       here: (i)
>
>       an Xt input handler process registered at program startup via
>
>       XtAppAddInput() which was periodically reading some non-X11 file
>
>       descriptor is deregistered, and (ii) a bunch of other non-stdio
>       file
>
>       descriptors are closed (presumably including the X11 display
>       socket). The
>
>       latter was written as a brute force loop that just tries to
>       close
>
>       everything in sight whether it might have been open or not, even
>       though
>
>       the manager seems to be opening only a couple of other file
>       descriptors
>
>       outside of X11.
>
>
>
>                pid= fork();
>
>                if (pid == 0) {
>
>                        XtRemoveInput(xtinputid);
>
>                        for (i= 3; i < 20; i++)
>
>                                (void) close(i);
>
>                        execlp("yada", "yada", "yada", 0);
>
>                        exit(-1);
>
>                }
>
>
>
>       Given that I want the gtk/gdk/etc. library code running within
>       my parent
>
>       manager process to remain ignorant of all children and continue
>       operating
>
>       as if there were none, my more particular questions with regard
>       to this
>
>       child process code are:
>
>
>
>       (1) Do I need to deregister the gtk input handler that I will be
>
>       substituting for the old Xt input handler?
>
>
>
>       (2) Do I need to explicitly call any kind of gtk shutdown or
>       main loop
>
>       exit function or should I very clearly avoid doing so?
>
>
>
>       (3) Should I do the same kind of brute force file descriptor
>       closedown as
>
>       the original code? Analogously to X11, I have to think this
>       would close at
>
>       least one gtk-opened decriptor, which might be something that I
>       should
>
>       definitely either do or NOT do.
>
>
>
>       (4) I read one archive reference that said children should
>       always use
>
>       _exit() rather than exit() in this context. Is that true, and if
>       so does
>
>       that apply only to the cleanup after a failed execlp() in this
>       fragment or
>
>       should it be done for all exit instances within the child's own
>       source
>
>       code as well? This processing system includes dozens of child
>       process
>
>       programs and doing the latter would be a real pain (and perhaps
>       have other
>
>       unwanted consequences for the child).
>
>
>
>       My gut instinct is that given that the exec() will give the
>       child process
>
>       an essentially clean slate EXCEPT for inheritance of open
>       descriptors, I
>
>       probably do want to close all non-stdio descriptors one way or
>       another
>
>       prior to the exec -- the essential question is how to do this in
>       a way
>
>       that causes no impact whatsoever to the gtk ennvironment of the
>       manager
>
>       parent.
>
>
>
>       Thanks!
>
>
>
>       Roger Davis
>
>       Univ. of Hawaii
>
>
>
>       _______________________________________________
>
>       gtk-app-devel-list mailing list
>
>       gtk-app-devel-list gnome org
>
>       https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list