Re: Gtkmm and fork()

[Chris Vine <chris cvine freeserve co uk>]

On Sat, 10 Apr 2010 09:17:45 -0400
MK <halfcountplus intergate com> wrote:
> Chris Vine wrote:
> >This won't work.  X won't allow two processes to share the same
> >resources.
> >If you are fork()ing to exec() another program, then you will need to
> >start a new thread and fork() from that 
> 
> You don't have to thread it.  I presume the purpose has nothing to do
> with gtk.  So you might as well quit() gtk immediately in the fork.
> After that you can do whatever you want.

Ah, that's an interesting approach.  It's good to know that
Gtk::Main::quit() is safe after a fork(): it is not something that I
have tried.  I generally eschew all main loop operations on the
inherited loop after a fork().

Fork()ing in a new thread has the advantage that if you are interested
in knowing when the child process ends and its exit status, the thread
can call a blocking waitpid() on it and extract the exit value.  That
saves having to mess about with SIGCHLD and asynchronous signals or
having a dedicated thread blocking on sigwait(). Alternatively of course
you could use a glib child watch in the main loop, provided GPid always
remains the same type as pid_t on unix-like platforms in the future (as
it probably will), but in that case the OP would be better off using the
glib spawning wrappers rather than calling fork() directly which would
save having to worry about that.

In a program which is already multi-threaded I think I would go down the
thread-fork route.  Where not, your solution looks good.

Chris