RE: deadlock

["Freddie Unpenstein" <fredderic excite com>]

> My name is Dirk, I'm writing a control programm for a 1m telescope
> in Germany. The current status of the device is periodically
> displayed in GTK using a thread.

Does it NEED to use a thread?  How do you get the information, and how long does it take to process an update?

The only times I've ever seriously considered using a thread is where you need to keep the GUI active (ie. 
processing of data takes a more than a second), there's a chance of the action blocking while fetching the 
data (DNS resolution is an example that often invokes threading), or you've got to handle a large number of 
distinct queries (in which case you usually get into thread pools and so forth).  For most other cases, async 
IO is usually quite sufficient, and mixing of threads and GUI's is a bad, bad idea.


> When the user clicks the quit butten a callback routine is started.
> At the same time my thread does a gtk_threads_enter(). But it
> cannot enter because the callback is running so it waits inside the
> gtk_threads_enter routine. My callback routine askes the thread to
> quit and waits for that to happen. But the thread cannot react
> because it is waiting inside gtk_threads_enter().

If reading and processing the incomming data takes so long or is so time sensitive that it needs to be done 
in a thread, how about reading and processing all the data ready for display first.  When you've got the 
numbers and texts to poke into the neccesary places, notify the GUI that new data is ready using 
g_idle_add().  A callback within the GUI thread can then take that data, shove it into the appropriate 
places, and continue on with barely a twitch.

If you're worried about both threads accessing the data at the same time, then wrap it up in a struct.  You 
can then either lock the struct so your monitor thread doesn't clobber it while your GUI thread is displaying 
it (which could delay your monitor thread, and may be unacceptible), or dynamically allocate the struct, then 
pass it along in the g_idle_add() call.  The GUI thread then simply free's the memory when it's done.  If 
you're afraid of the GUI thread stalling and eating memory (how big is this struct anyway?!?), you could 
either delete the old idle callback before creating a new one (I believe the g_idle_add_full -- or 
thereabouts -- function has the ability to attach a cleanup function), or use a variable to hold the struct 
pointer, and lock that (To send; read the current value, write our new pointer, then unlock and free the old 
struct if neccesary. To receive; read the value in the variable, and write back a null to indicate it's been 
read, then unlock and star
 t prodding the GUI).

But whatever you choose to do, I'd personally make a point of keeping GDK/GTK well out of anything but your 
GUI thread, and keeping your locks as brief as possible.  As a matter of course, I generally aim to split the 
program into GUI and non-GUI parts, so I could either turn the non-GUI parts into a libXXX package or turn 
the GUI parts into a runtime linkable module and roll together a KDE/console/web/etc. version at a later date.


Oh, and is there any way you could ask the monitor thread to end itself, instead of trying to kill it from 
the GUI thread?  I've always tried to teach components to shut themselves down, rather than relying on 
someone else to do it.


Just a few ideas to consider.

Fredderic

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!