Re: strange deadlock ... - corba sidetrack

[Michael Meeks <michael ximian com>]

Havoc,

	Can we move this rather peripheral discussion to gcl ?

On 18 Jul 2001, Havoc Pennington wrote:
> Michael Meeks <michael ximian com> writes: 
> > 	I remember you having issues with re-enteracy - but this is
> > inevitable - but perhaps you have some cunning new scheme for avoiding
> > re-enterancy ? I'd be most happy to hear it.
> 
> I'm sure this has been discussed before, but in the interests of
> bringing everyone up to speed on all the issues - why are we blocking
> in the main loop on outgoing calls, instead of full-blown blocking on
> the file descriptor where we expect to hear back from the server?

	We are using GIOChannels to handle IO, furthermore, we need to be
able to handle incoming CORBA calls anyway - re-enterancy is part of life
if you get handed a Bonobo_Unknown reference and want to increment the 
reference count on it - and the owner at the other end doesn't accept
incoming calls until the method terminates you have an even more evil
situation where every common interaction locks up.

	Conclusion 1.: re-enterancy is vital to CORBA, and should not be a
major problem, I don't understand the issue in Nautilus particularly - I'm
sure Darin will expand on gcl.

	Conclusion 2.: this has nothing to do with the Gtk+ problems which
need addressing.

	Conclusion 3.: it would be nice if we could stop Gtk+ / X events
causing yet more unwanted additional re-enterancy - this is a real
pain. ie. the ORB has to do a g_main_loop_iterate, but is only really
interested in processing events coming in from a small group of
GIOChannels - the CORBA connections, and is extremely uninterested in
processing random X events [ esp. destroy type events ].

	So ... if we had a solution something like:

	* Group polls in the main loop
	* Allow g_main_loop_iterate to poll a subset eg. 'CORBA IO'
	* update g_main_context_query to reflect the grouping.

	Or a more flexible one, whereas one could specify a separete
GPollRec *poll_records, guint len type set of fds' to poll.

	Either way, while any solution like the above might (peripheraly)
solve the immediate problem of Gtk+ deadlocking [ since gtk+ events
couldn't be processed in that scope ], it would not get rid of the
(serious) GDK_THREAD_ENTER / LEAVE evilness.

	In many ways while the above solution would be nice, it can only
be done currently by doing violence to glib or replicating great chunks of
it - which is not nice.

	So ... probably better to fix the Gtk+ issues,

		Michael.

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