Re: gtk3 and fork/exec of non-gtk child
Hi Roger, I put together a test example of GSubprocess. It starts Gnuplot, sets up the pipes and callbacks, and then when Gnuplot is done it opens the graph in an image widget. The GSubprocess will take care of the file descripters for you. ... https://github.com/cecashon/OrderedSetVelociRaptor/blob/master/Misc/Pipes/gnuplot5.c This might not be what you are looking for since it is a little higher level than using a spawn function but there are a lot of things set up with GSubprocess that make it worth consideration. Options. You can do some nice plotting with GTK+ and Gnuplot also. Eric Thank you very, very much, Eric! I will definitely take a look at that. Roger PS: I think you submitted this to the wrong thread by mistake (I just opened a second topic on this list), so I am replying in the correct thread instead. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk3 and fork/exec of non-gtk child
On 2017-01-14 01:51 PM, Eric Cashon via gtk-app-devel-list wrote: Hi Roger, A little while back I was testing something similar with g_spawn_async_with_pipes(). It is neither mission-critical or meticulous but something I was just testing for the possible use with gnuplot. There is a driver.c and a worker.c program. The driver spawns the worker and sets up some communication. You just need to set the location path of the worker in driver.c. Sort of simple but I had some trouble figuring out how some of this worked so... it might be helpful. https://github.com/cecashon/OrderedSetVelociRaptor/tree/master/Misc/Pipes I haven't used GSubprocess and don't know of a short starter there. Eric ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list I too have used g_spawn_async_with_pipes() and GIOChannel's to spawn child processes that monitor USB temperature probes and pipe the data back to a main program. For me it was important that the children were asynchronous and independent. The child processes have no GUI or direct user interaction (except through the main program). I have no problem spawning multiple child processes (for multiple probes) and can easily stop them at will by sending them a signal along the pipe to close them down. The code is very similar to Eric's, albeit buried in a much larger program. I haven't used GSubprocess either but in looking at it, it looks pretty interesting. jim... ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk3 and fork/exec of non-gtk child
Thanks much for the suggestions and code pointer, Eric! I get the drift that GSubProcess is a more recent package layered over g_spawn. It consequently seems to have more features but less 3rd-party documentation outside the reference manual. Roger On Sat, 14 Jan 2017, cecas...@aol.com wrote: Hi Roger, A little while back I was testing something similar with g_spawn_async_with_pipes(). It is neither mission-critical or meticulous but something I was just testing for the possible use with gnuplot. There is a driver.c and a worker.c program. The driver spawns the worker and sets up some communication. You just need to set the location path of the worker in driver.c. Sort of simple but I had some trouble figuring out how some of this worked so... it might be helpful. https://github.com/cecashon/OrderedSetVelociRaptor/tree/master/Misc/Pipes I haven't used GSubprocess and don't know of a short starter there. Eric ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk3 and fork/exec of non-gtk child
Hi Emmanuele, On closer reading there are some details of GSubProcess implementation and usage that are unclear to me. I have not been able to find anything resembling a tutorial anywhere, if you are aware of anything useful other than the base GSubProcess reference manual page please advise. Or, if there is a better forum to ask these questions, also please advise. Here's what is still unclear to me about the suitability of GSubProcess for my code: (1) Is there a ROCK-SOLID guarantee that the death of all child processes will be reported one-for-one with GSubProcess? My understanding of fork/exec/SIGCHLDhandler is that it is possible for there to be only one SIGCHLD made pending on a process even if multiple children have exited. This is dealt with by having the SIGCHLDhandler implement a loop which is capable of waitpid()ing on multiple children. How does GSubProcess cope with this issue? Is SIGCHLD even used at all, or is there a hidden SIGCHLDhandler somewhere that does waitpid()-ish looping? My app absolutely must know when each and every child dies (within a reasonable latency) or it's worthless. (2) I see a g_subprocess_new() but no corresponding g_subprocess_destroy(). I will potentially have many children exiting and restarting and would prefer not to burn through the heap with scads of expired useless GSubProcess objects. I am not at all familiar with glib/gobject/gio in general, so I assume I am missing something totally obvious here. (3) The GSubProcess doc page does not explicitly state this, but I get the impression from reading related pages (GAsyncResult) that the handler I register with g_subprocess_wait_async() is required to call g_subprocess_wait_finish(). Is this true? Thanks! Roger ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk3 and fork/exec of non-gtk child
Hi Roger, A little while back I was testing something similar with g_spawn_async_with_pipes(). It is neither mission-critical or meticulous but something I was just testing for the possible use with gnuplot. There is a driver.c and a worker.c program. The driver spawns the worker and sets up some communication. You just need to set the location path of the worker in driver.c. Sort of simple but I had some trouble figuring out how some of this worked so... it might be helpful. https://github.com/cecashon/OrderedSetVelociRaptor/tree/master/Misc/Pipes I haven't used GSubprocess and don't know of a short starter there. Eric ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk3 and fork/exec of non-gtk child
Hi Emmanuele, Thanks very much for that additional explication, and I think your reasoning on these issues is quite sound. I am being particularly careful about making changes to working code here for two reasons. First, this is mission-critical software running on a research vessel at sea -- if it fails, (i) there will be no programmer on board who can fix it and poor off-ship comms make it virtually impossible for a programmer on shore to fix it either, and (ii) the jaw-dropping daily ship operation costs make failure absolutely unacceptable (and employment-threatening ;-> ). Second, despite the fact that the operating environment for the child processes is complex and unstable (they are communicating with sensors that might euphemistically be described as moderately ephemeral), the original code seems to cope with it quite adequately. Thus, the "ain't broke ---> don't fix" law applies strongly here. The part of the code that IS broken is the Motif, which has become increasingly difficult to maintain (as X11 itself will likely be in a few more years), hence the gtk3 port. I think that perhaps what I will do is create two versions, one with GSubProcess and one with fork/exec. The former will be used preferentially unless it breaks, at which time the latter can be substituted as a fallback. Given your statement that I don't need to do anything special after forking (like deregister a gtk input handler or anything else related to gtk?), then the following fork-to-exec segment should work, yes? pid= fork(); if (pid == 0) { for (i= 3; i < 20; i++) (void) close(i); execlp("yada", "yada", "yada", 0); exit(-1); } Note that I am still using the original brute force loop to close miscellaneous non-stdio descriptors. Probably one or more of these will be gtk-related, would that be a problem? If so, I would need to be more meticulous on this point, perhaps tracking down all of the parent's other open descriptors and making them close-on-exec like gtk's. Thanks so much for your help! Roger On Sat, 14 Jan 2017, Emmanuele Bassi wrote: Hi; On 14 January 2017 at 16:24, rbd 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. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk3 and fork/exec of non-gtk child
On Sat, 14 Jan 2017 06:24:18 -1000 (HST) rbd wrote: > 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. If you want to go by POSIX, then you can only call async-signal-safe functions between the fork() and the exec(). Your code called XtRemoveInput() and close(). close() is async-signal-safe. I have no idea whether XtRemoveInput() is, but I doubt it. This rule would ordinarily preclude calling anything which might allocate or free memory between fork() and exec() (none of those are async-signal-safe), but glibc provides atfork handlers for the allocator mutexes which actually makes that safe, and glib's g_spawn* family rely on that. But not all allocators are: Chromium's tcmalloc allocator definitely is not, so you have problems if that gets linked into your code. Caveat forkor. Just use the stuff glib provides, as suggested. Chris ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk3 and fork/exec of non-gtk child
Hi; On 14 January 2017 at 17:17, infirit 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
Re: gtk3 and fork/exec of non-gtk child
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. ~infirit [1] https://jameswestby.net/weblog/tech/14-caution-python-multiprocessing-and-glib-dont-mix.html ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk3 and fork/exec of non-gtk child
Hi; On 14 January 2017 at 16:24, rbd 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 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 g
Re: gtk3 and fork/exec of non-gtk child
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 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
Re: gtk3 and fork/exec of non-gtk child
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 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
gtk3 and fork/exec of non-gtk child
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