RE: GTK and threads

["Boncek, John" <jboncek hunter com>]

How did you get an attachment to work with the list?  I have never known
that to work and often wished it would.

-----Original Message-----
From: gtk-app-devel-list-bounces gnome org
[mailto:gtk-app-devel-list-bounces gnome org] On Behalf Of Michael Torrie
Sent: Monday, February 06, 2006 1:22 PM
To: kornelix
Cc: gtk app dev mail list
Subject: Re: GTK and threads

kornelix wrote:
> Thanks. I eagerly anticipate your example.

I have attached a sample file that uses threads in the way you described 
in your last post.  The gui consists of a single text display and a 
button.  When you click the button, a new thread is started that 
periodically (every second) sends a message to the text window.  When 
you close the window, the program will send a signal to each thread to 
terminal (well not a real signal, just sets a flag).  Once all the 
threads have terminated, the program ends.  I have not implemented a 
proper signalling system to send signals to the threads nor have I used 
the pthread_join to properly rejoin threads that have quit.  Mainly 
because pthread_join blocks and that causes problems.

You'll notice the on_destroy callback has a loop that iterates the gtk 
event loop while we're waiting for the threads to stop.  This is because 
we're in a callback, already holding the gdk_thread_lock, so any waiting 
in here will prevent threads from aquiring their lock and thus finishing 
their loops.  So we iterate it.

The callbacks (including the pthread_create calls) already occur in the 
context of the main gdk lock, so no explicit locking is needed there.

See what you think.


> I made a small code example like the one you described. It hung up. Then

> I figured out why: I am calling a function that has the 
> gdk_threads_enter() and _leave() wrappers from main() as well as from a 
> created thread. In the case of main(), the call to gdk_threads_enter() 
> was a second call for that thread, and this is apparently fatal. I have 
> to figure out how to detect and avoid this, or make multiple versions of

> the functions with and without the wrappers. If I call the function from

> the thread only, it works.

I really am not following what you are describing (please provide code) 
but it feels like you're definitely doing something wrong.  It needn't 
be this complicated from my experience.

> One way of looking at the issue is that the FAQ example includes all 
> main() code within the thread wrapper functions, meaning that any called

> functions better not have the wrappers. Would it be legitimate to treat 
> main() like any other thread, and put the wrappers only around gtk/gdk 
> calls? If I could do this, then functions would be usable from both 
> main() and created threads.

Hmm.  Sounds complicated.  My gut feeling is that most of your 
difficulties are in not knowing when you are in the gdk lock already and 
when you need to initiate a lock.  Please tell me if my example code 
addresses any of the problems you have been having.  (and for the real 
GTK experts out there, feel free to point out where I'm doing everything 
wrong.)

Michael


> It will not take long, so I will just try this.
>
> regards