Re: multi-threaded apps.



What you said is pretty much what I want to do, but I am worried about code
that tries to take the lock twice.

Say for example I have a function in my app:

my_app_function()
{
	... blah ...
	gdk_threads_enter()
	gtk_foo()
	gdk_threads_leave()
	... blah ...
}

now this function can be called either from a callback, or from a thread.

My problem is that, if I call my_app_function from a callback, the
gdk_threads_enter will block, since it is a non-recursive mutex, and the lock
is already held. I can't just remove locks, because then I can't call
my_app_function from a thread. I could release the lock for the call to
my_app_function, but that seems counter-intuitive.

I suppose a solution is to wrap calls to my_app_function with the lock, and
not
lock in the function, but I was hoping to avoid this (because some of the
functions go for long periods without needing the lock).

Having said all this, I am not actually seeing the behaviour I expect (ie a
lockup) when I wrap all the gtk_* calls in libbalsa with locks, so maybe I
have
missed something important??

Ian.

On Mon, 21 Aug 2000 22:56:24 Havoc Pennington wrote:
> 
> Ian Campbell <ijc25@cam.ac.uk> writes: 
> > Any clues/hints?
> > 
> 
> Just hold the lock around GTK calls:
> 
>  gdk_threads_enter ();
>  
>  gtk_foo ();
> 
>  gtk_bar ();
> 
>  gdk_threads_leave ();
> 
>  my_own_app_function ();
> 
>  gdk_threads_enter ();
>  
>  gtk_blah ();
> 
>  gdk_threads_leave ();
> 
> In a callback, you can just access the GUI since the lock is already
> held, right?
> 
> Havoc






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]