Re: Thread programming

[Justin Hopper <gus gusalmighty com>]

On Mon, 2003-06-16 at 06:41, Tristan Van Berkom wrote:
> 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

Thanks, Tristan (et al.).  This seems like a very logical approach. 
Just as a side note, I tried debugging the application with gdb, but it
only showed:

[New Thread 1080082400 (LWP 28716)]
[New Thread 1090956592 (LWP 28717)]

So, I would probably have to use something like Valgrind to see where
the collision is occuring.

However, I'd rather pursue the idea of sending a message to the main
thread to update the GUI, and have all GUI updates done through that.  

Now my question is obvious: how do I notify the main loop?  I saw a few
examples of gtk_signal_emit_*, but where do I catch these signals in the
gtk_main loop and update certain things?  Just to make sure I've given
the right background information:

// main.c
...
pthread_create(&check_tid, NULL, check_queues, window1);
...
gdk_threads_enter();
gtk_main ();
gdk_threads_leave();

The thread that is spun off will have data that needs to be passed to
the main loop for the GUI.  Using this method, do I need to enter and
leave threads in main.c or in the check_queues function?

Thanks again for all the help.

> _______________________________________________
> gtk-app-devel-list mailing list
> gtk-app-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
-- 
Justin Hopper <gus gusalmighty com>