Re: Thread programming

[Tristan Van Berkom <vantr touchtunes com>]

Justin Hopper wrote:

> On Sun, 2003-06-15 at 07:03, Havoc Pennington wrote:
>  
>
> > On Sat, Jun 14, 2003 at 04:39:24PM -0700, Justin Hopper wrote: 
> >    
> >
> > > I've read the FAQ on thread programming, but I must be missing something
> > > fundamental on how they work.
> > >
> > > Any help is greatly appreciated.
> > >      
> > Thread lockups are generally one thread stuck on a lock that's owned
> > either by another thread or that was locked earlier by the same
> > thread.
> >    
>
> One thing I should mention is that I only have one thread running in the
> background.  I assume the GUI runs in it's own thread, so that would
> make a total of two threads.  I'm not doing anything in the GUI when it
> locks up, but perhaps it is have trouble just reading the label that was
> updated in the background thread.  I should also mention that the
> background thread never locks up either, it keeps trucking along.
>
> Can anyone confirm whether or not doing simple thread programming will
> work while using libglade?
>
>  
When Havoc said he didnt think libglade was "thread-safe"; I dont know if he
meant the run time utility or the code that it generates. It is probable 
that glade
doesn't generate code with mutex locks on object access et cetera et cetera
but other than that, If you use glade to generate/parse an XML widget 
layout;
the job is quite simple.

- Use the glade_xml_get_widget(xml, "name") API
- Make _SURE_ that this is done in the same thread that you will access 
the "created objects"
- Use threads to do lengthly background jobs and dont update any GUI 
memory space objects
 from that thread. (i.e. if you do a db query that returns 10 elements 
every `n' millies; pass those
 to the gui thread to update your "listview" or whatnot; dont update 
directly).
- If you use "sources" in your thread (i.e. g_timeout_add), make sure 
that your thread has its own
 GMainLoop running.

If you follow this strict practice, I garauntee it will work. (well, it 
works for me ;-) )
There have been a bunch of extra stuff added to make thread programming 
in gtk
more solid et cetera since "gtk+-2.x" (i.e. gdk_threads_enter/leave) 
which allow you
to do even cooler stuff.

Note. gdk_threads_enter/leave are by no means nescisary if you follow 
the above prectice.
(I'm guessing that this is just a wrapper for some global mutex for the 
"drawing kit").

Also ofcourse I have to agree with Havoc about the backtrace;
may I recommend Valgrind ? it will tell you where and when a posix mutex
gets locked _or_ unlocked twice by the same thread (I though that was
pretty neat).

Cheers,
                   -Tristan