Re: strange deadlock ... - corba sidetrack

[Owen Taylor <otaylor redhat com>]

Michael Meeks <michael ximian com> writes:

> 	Can we move this rather peripheral discussion to gcl ?

There are people on gtk-devel-list who most likely have definite ideas
on the matter.
 
> 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.

I believe the common use case for CORBA is to use threading to get
much more controlled concurrency then allowing arbitrary incoming
calls 

Do you seriously believe that most people using Bonobo realize
that when they make any Bonobo call, as trivial as Bonobo_Unknown_ref,
that _absolutely anything_ can happen? Do you believe they are
writing their code to be robust against it?

Except for the core GTK+ code, almost no GTK+ code properly handles
reentrancy from signal handlers, and this is much more predictable
and restricted than allowing reentrancy for all Bonobo calls.

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

I'll let you read the section of the FAQ before saying more
on this issue.

> 	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.

Actually, the recent changes to GMainContext were done primarily so
Sebastian could do exactly this in ORBitMT. Though it doesn't really
solve ORBit's problems with uncontrolled reentrancy, since its pretty
easy to have reentrancy problems using only CORBA calls.

And also, if you don't know if you have the GTK+ lock or not
when you get an incoming call, you cannot make any calls to
GTK+.
 
> 	So ... probably better to fix the Gtk+ issues,

I'm yet to be convinced there is a "fix" (or at least short of
a 6-month-of-work fix). If you want to use GDK/GTK+ in threaded
mode, you need to care minimally about the GDK lock.

Regards,
                                        Owen