Re: locks in signal callbacks

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

 



On Mon, 2004-07-12 at 17:49, Stefan Holst wrote:
> hello!
> 
> i'm currently developing a multithreaded application which uses gtk+.
> this application has beside the gtk+-lock some other mutexes which have
> to be locked in a defined order to avoid deadlocks. in particular these
> locks have to be obtained before a gtk+-lock.
> 
> now here are my questions:
> as i learned, signal callbacks already have a gtk+-lock. so if i have
> to obtain my application-specific locks, may i use the following
> construct to avoid deadlocks?
> 
> g_threads_leave();
> lock(my_mutex);
> g_threads_enter();
> 
> or will this lead to trouble within the gtk-lib?

It generally should be fine. GTK+ is designed to be quite reentrant
over signal callbacks. The one place you will get into trouble is
if you do that in a signal connection to ::size-allocate ::size-request
::map or similar calls that are part of an operation on the widget
hierarchy and then mutate the hierarchy from another thread.

But for ::clicked, ::key-press, ::active, etc, should be fine.

Regards,
						Owen


Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________

gtk-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-list

[Index of Archives]     [Touch Screen Library]     [GIMP Users]     [Gnome]     [KDE]     [Yosemite News]     [Steve's Art]

  Powered by Linux