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

[Jim Charlton]

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

[rbd]

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

[rbd]

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

[Eric Cashon via gtk-app-devel-list]

 
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

[rbd]

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

[Chris Vine]

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

[Emmanuele Bassi]

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

[infirit]

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

[Emmanuele Bassi]

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 

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

[rbd]

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 

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

[Emmanuele Bassi]

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