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