Re: Help: multithreaded GNOME app

[fraioli dg-rtp dg com (Marc J. Fraioli)]

> 
> Look into condition variables.  Basically, the gtk thread could sleep
> while waiting for the length of the queue to become more than 0.  Then any
> time another thread added something to the queue, it would wake up the
> sleeping gtk thread.
> 

I may be misunderstanding what you're suggesting here, in which case I
beg your forgiveness in advance.  But if I'm following you correctly, I
don't think this is a desirable thing to do.

The GTK thread (by which I assume you mean the thread that calls
gtk_main()) shouldn't ever block anywhere but inside of gtk_main().  If
you call pthread_cond_wait() from that thread somewhere, then it won't
get back into gtk_main(), and it will become unresponsive to other
events that it ought to be attending to.  Thus if the screen gets
refreshed, the window will stay blank, not being redrawn, etc.  The GUI
will not respond to button presses, etc.  Generally not desirable.

I think the basic strategy to follow is the one he is already
following; the GTK thread has one end of a pipe multiplexed in with the
other things it listens for in gtk_main().  The other thread or threads
send it notifications on that pipe, which indicate that it should look
in some other pre-arranged place for what the real message is.  This
other pre-arranged place will probably be some shared piece of memory,
protected by a mutex.  A callback function aquires the mutex and checks
that spot when data comes over the pipe.  This is a bit clunky, but if
the GUI libraries themselves aren't threadsafe, you're not going to get
a really beautiful solution, probably.  And this ought to work fine; 
I've used similar schemes before, though not with GTK.

	Marc