Re: Multi-threading

["Douglas C. MacKenzie" <doug mobile-intelligence com>]

I agree with the "common trap" assessment.

I have my own semaphore that is poorly named "gtk_lock"
that I use to synchronize access to gtk from my threads.
My problem is trying to get a main thread to block for events
without holding MY semaphore, then grab it and process
the events.

I'm now thinking I really should just use the GTK semaphore.
I will read up on the g_thread_enter and g_thread_leave calls.

Doug

On Wed, 2006-04-05 at 16:29 -0400, Paul Davis wrote:
> On Wed, 2006-04-05 at 15:58 -0400, Douglas C. MacKenzie wrote:
> > Along these same lines, I would like to do:
> > 
> >   while( Gtk::Main::wait_until_events_pending())
> >   {
> >      synchronized( gtk_lock )
> >      {
> >         while( Gtk::Main::events_pending())
> >            Gtk::Main::iteration();
> >      }
> >   }
> > 
> > But I can't find a method that will block until
> > an event is pending, without processing that event.
> > Or, is it a problem to even wait for events to be
> > pending if another thread is updating gtk stuff
> > inside another block synchronized to my gtk_lock?
> 
> this falls into a common trap/misunderstanding of how the global gtk
> thread lock works. it took me a while to understand it and by then i
> gave up on using the lock at all.
> 
> the lock is acquired by gtk when the event loop returns from blocking
> (in the kernel) on some set of descriptors (e.g. the socket connecting
> you to the X server). it is released before re-entering that blocking
> call. 
> 
> so, you do not hold the lock unless you are handling events *or* making
> "out of bounds" calls to GTK functions. this means that if you want to
> make a GTK call (e.g. gtk_widget_queue_draw()) from another thread (say,
> because some thing happened in that thread that isn't handled by GTK),
> you must first acquire the lock to make sure that a different thread is
> not processing GTK events and thereby prevent any parallel execution of
> GTK functions. when you are done, you drop the lock, allowing other
> threads to process GTK events in the normal way.
> 
> --p
> 
>