Re: strange deadlock ... - GMainContexts

[Michael Meeks <michael ximian com>]

On 18 Jul 2001, Owen Taylor wrote:
> I believe the common use case for CORBA is to use threading to get
> much more controlled concurrency then allowing arbitrary incoming
> calls

	I don't see how threading helps, you still get re-enterancy, but
then you have to lock everything and you still get things shifting under
your stack.

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

	Well, like it or not there is no better solution proposed by
anyone, it's all very well to moan about it :-) but it seems to be the
only way to me.

	I imagine what _really_ screws people up is having non-CORBA
re-enterancy messing them about - ie. all manner of other peripheral
irrelevant events being processed when we hit g_main_loop_iterate.

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

	Yes - I take that back, it's possible that the Gtk+ threading
feature can't be done in the way that I'm used to seeing in real time :-)

> Actually, the recent changes to GMainContext were done primarily so
> Sebastian could do exactly this in ORBitMT.

	Ahh, I read it again - I assume then that Sebastian sets up his
own GMainContext for the CORBA descriptors ?, in which case how does he
integrate with a Gtk+ program ?

	Is it possible to have ( in the default case ) multiple
GMainContexts [ the default Gtk+ one, and the CORBA one ] blocking waiting
for input - and reserve just blocking on the CORBA Context for these
re-enterancy cases ?. Clearly it is not desirable to have a little loop
belting round polling two contexts in a non-blocking fashion.

> Though it doesn't really solve ORBit's problems with uncontrolled
> reentrancy, since its pretty easy to have reentrancy problems using
> only CORBA calls.

	The 'uncontrolled' re-enterancy is not a problem that can be
solved, without killing the flip-side of actualy being able to call back
into an object that has been handed you without fear of deadlock.

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

	Again, the gdk event handler goes and makes these calls itself
when you hit the g_main_loop_iterate.

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

	Yes, I understand this better now, thanks.

	Regards,

		Michael.

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