Hi; On 14 January 2017 at 16:24, rbd <r...@soest.hawaii.edu> wrote:
> 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. Instead of GSubprocess, you could even use g_spawn_async() and friends: https://developer.gnome.org/glib/stable/glib-Spawning-Processes.html Which is what GSubprocess uses anyway, though it's harder to set up and still does not provide everything you may need without having to reimplement it yourself. The reason why I'm suggesting you to use the API provided by GLib and GIO is that it's reliable, well tested, and maintained to take into account changes in the userspace of modern system. For instance, GSubprocess uses O_CLOEXEC to avoid leaking file descriptors from parent to child; it uses a watcher thread to ensure that communication and Unix signals are handled correctly, race free, and delivered to the right main context; it controls the environment used to spawn the child process in a safe way; it allows non-blocking handling of communication between parent and multiple children. In short: I would not generally recommend throwing away working code, but I would strongly suggest using the safest implementation provided by the platform you're targeting. Old code may be still working, but does not imply that it's working according to the best practices of modern systems. If the code in question is as old as you mention, written for a very different era, then you may end up paying the technological debt later on. Ciao, Emmanuele. > 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 <r...@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 >> >> > -- 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
