Re: strange deadlock ...

[Michael Meeks <michael ximian com>]

Hi Owen,

On 17 Jul 2001, Owen Taylor wrote:
> The basic idea here is that you need to release the GTK+ lock before
> calling g_main_loop_run() or g_main_context_iteration().

	Ok, sounds reasonable.

> Of course, you are sort of in a pickle here because
> giop_recv_buffer_get() has no idea whether it has the GTK+ lock or
> not, and you presumably don't want to require everybody to release the
> GTK+ lock before making all CORBA calls.

	Yes, quite.

> But on the other hand, if you are doing a recursive main loop -- and
> you are -- then you _do_ have to release the GTK+ lock.

	Hmm.

> I don't really have a good solution - as soon as you call
> g_thread_init(), then suddenly your required to think about situations
> that come up when you are using GTK+ from multiple threads. I'll think
> about it some more and see if I come up with a suggestion.

	The thing is - that this is not a multi-threaded program, it is
merely a single thread. Simply run libbonoboui/tests/test-selector[1] and
click 'get Id' and hey presto.

	Hmm,

		Michael.

> > #4  0x4034f0de in gdk_event_prepare (source=0x8063660,
> > timeout=0xbfffe0b8) at gdkevents-x11.c:1702
> > #5  0x407570a5 in g_main_context_prepare (context=0x8051938,
> > priority=0xbfffe0f8) at gmain.c:1904
> > #6  0x4075792f in g_main_context_iterate (context=0x8051938, block=1,
> > dispatch=1, self=0x8050040) at gmain.c:2190
> > #7  0x40757bc7 in g_main_context_iteration (context=0x0, may_block=1) at
> > gmain.c:2269
> > #8  0x405ce1c2 in giop_recv_buffer_get (ent=0xbfffe1e0,
> > block_for_reply=1) at giop-recv-buffer.c:812
> > ...
> > #42 0x401e403d in gtk_main_do_event (event=0x80f7530) at gtkmain.c:926
> > #43 0x4034f247 in gdk_event_dispatch (source=0x8063660, callback=0,
> > user_data=0x0) at gdkevents-x11.c:1745
> > #44 0x40756d88 in g_main_dispatch (context=0x8051938) at gmain.c:1593
> > #45 0x407576b5 in g_main_context_dispatch (context=0x8051938) at
> > gmain.c:2129
> > #46 0x40757a50 in g_main_context_iterate (context=0x8051938, block=1,
> > dispatch=1, self=0x8050040) at gmain.c:2210
> > #47 0x4075810e in g_main_loop_run (loop=0x80f8520) at gmain.c:2430
> > #48 0x4057a8ae in bonobo_main () at bonobo-main.c:276
> > 
> > 	The problem being of course that gdk_event_dispatch is holding the
> > GDK_THREADS_ENTER mutex, that gdk_event_prepare tries to take.

[1] - test_selector being a worryingly trivial test program.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot