Re: [gtk-list] Threads and GTK+

[Paul Barton-Davis <pbd op net>]

>I have a GTK+ app that would like to fork in one spot and either execute a
>program that does non-GTK+ X related stuff, or just call the code after a
>fork inside the GTK+ program AFTER closing all GTK+ related resources that
>the child inherited from the parent process.  Neither works.  I get
>messages that say  Xlib:  unexpected async sequence and then some badass
>BadFont errors from X when certain ExposeEvents get sent to the parent
>GTK+ app.
>
>How to get around this?  I know you're not supposed to use threads in
>GTK+, and I'm trying to bend over backwards to avoid it.  Is it not
>possible to fork and execute any X related code in the child at all
>without screwing up the parent?

Note: fork(2) does not create just another thread - it creates a new
task (a process in traditional Unix). if you want to use threads,
consider using POSIX threads via a pthreads library (its part of GNU
libc). this is no small matter.

assuming from now on that by "thread" we mean something created with
pthreads: 

one solution that i have used is to create a pipe that the non-GTK
threads can write to when they want to ask the GTK thread to do
something. you multiplex the pipe into the main loop of GTK, and use a
special handler when data is readable from the GTK end of the
pipe. you just define a convenient struct for the "protocol" spoken
between the GTK thread and the rest, and away you go.

i use this system in several programs, some of which have up to 5
threads talking to a single GTK-using thread. it works very nicely.

>A related question is whether or not child fork()ed processes inherit heap
>memory as pointers, or as heap memory.  If I do say,

RTFM. fork creates a new task with an entirely new address space. no
memory address in one address space has any specific meaning in
another. if you don't understand this, i am not sure you should be
trying to write a multithreaded program until you've sat down and read
some more books.

--p