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
