On Sat, 10 Apr 2010 09:17:45 -0400 MK <[email protected]> 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 _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
