Re: [gtk-list] Threads and GTK+

[Erik Mouw <J A K Mouw its tudelft nl>]

On Mon, 08 Nov 1999 23:50:20 -0500 (EST), Matthew D Allen wrote:
> I've read the FAQ, and basically everybody I have talked to has told me to
> never use GTK+ in a thread, so I don't, but I was trying to skirt across
> the issue when I ran into a problem that I was hoping somebody might have
> some info on.

Why not? GTK is thread safe. If you're looking for a threads example: I
posted one a month ago on this list (and some other people corrected some
errors), you should be able to find it in the mailinglist archives. Look
for the subject "RFC: ".

> 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.

Don't even close the GTK stuff in the child, just ignore it.

> 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?

No, it's not possible.

> A related question is whether or not child fork()ed processes inherit heap
> memory as pointers, or as heap memory.  If I do say,
> 
> myptr = g_new(char, 1024);
> 
> if(fork()==0)
> {
>    /* Is myptr in here heap memory that should be g_free()d or is a 
>     * regular pointer  (connected to parent memory?)
>    */
> }
> 
> exit;

The parent and the child are two separate processes. You allocated the
memory in the parent, when you fork, the child gets a copy of the parent's
address space, so it also gets a copy of the memory allocated to myptr.
Bottom line: yes you have to g_free() it.

> If anybody knows how to "cheat" gtk+ and get non-gtk+ threading to work,
> I'd appreciate hearing about it.  The process I want to execute in the
> child process will basically wait and wait and wait indefinately, so I
> can't do it without forking otherwise my program won't return to gtk_main
> after the callback and continue to do vital things like redrawing, etc.

Wait on what? If it is a blocking I/O operation, use gdk_input_add() to
get called once the file descriptor is ready. If it is something else, use
a timeout function (with gtk_timeout_add()).


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2785859  Fax: +31-15-2781843  Email J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/