Re: ORBit2 / GMainContext locking: nurgh ...

[Jules Colding <colding omesc com>]

On Thu, 2005-11-17 at 16:45 +0000, michael meeks wrote:
> Hi guys,
> 
> 	So - we have an evil problem in OO.o - and I was hoping there would be
> an easy solution; but - it turns out to be substantially more ugly than
> you might imagine. Just posting my notes & current (non-working) patch
> before I abandon trying to fix it (for now).
> 
> 	The problem is essentially that ORBit2 remembers what the 'main' thread
> is (which it is initialized with). 

I have, for other reasons, struggled with this too. See:

http://mail.gnome.org/archives/orbit-list/2005-September/msg00014.html

This may or may not be of any help, but my "cure" has been to:

1) spawn a thread that creates the orb, executes ORB_init() and finally
ORB_run() in my application process.

2) create a proxy ORBit2 process that wraps objects that lives under the
orb in (1) within objects that lives in the daemon process. 

The above gives me no troubles with orb life times or exposing objects
to remote clients, even if the original orb in (1) is local-only.


-- 
  jules



> It does this for compatibility
> purposes, and when you invoke a CORBA method on an in-process
> implementation that is not tagged as thread-safe, it tries to proxy that
> call into this known-in-advance 'main' thread.
> 
> 	There are 2 problems I've seen so far with this:
> 
> 	a) if you init the ORB from a short-lived thread, (ie. not at
> 	   startup), then really-bad-things-happen when that thread dies
> 	   ie. this 'main-thread' assymetry has to be reflected in the
> 	   callers code.
> 		+ This -unfortunately- means we have to initialize 
> 		  ORBit2 (& gnome-vfs) at OO.o startup => ugly
> 		  performance issue.
> 
> 	b) if you have a thread which wins the GMainContext ownership
> 	   (as can easily happen with multiple threads using the same
> 	    context), then if you call a CORBA method to an object that
> 	    does not have this 'thread-safe' tag set - from a different
> 	    thread to that in which the ORB was initialize - you 
> 	    deadlock.
> 		+ This happened with the a11y code - but as long as we
> 		  restrict our CORBA use to remote CORBA impl.s (which
> 		  is easy there) this should be no problem.
> 
> 	Anyhow - I had a good go at fixing it. This is particularly hindered by
> the rather inflexible & unpleasant GMainContext API pwrt. determining
> whether the current thread owns that context, and the
> 'g_main_context_wait' API being useless [ since it doesn't wake the main
> thread -> you can block forever easily ].
> 
> 	Unfortunately I ran out of steam debugging the proposed solution; it's
> still not clear to me which thread queue to mux incoming requests to -
> quite likely I need to re-work the per-thread queue concept
> substantially, perhaps removing it in favour of a single, more simply
> locked central request pool.
> 
> 	Either way - for OO.o / a11y the moral is clear - do only remote CORBA
> IPC; ie. don't use Bonobo_Unknown_unref in-process in OO.o, but only
> bonobo_object_unref - etc.
> 
> 	Another point to mention is that currently ORBit2 allows a rather
> un-advertised feature whereby if you are in the 'main' thread and issue
> an *explicitely* async call [using the custom ORBit2 stub API for this ]
> it will give you an async callback in the glib mainloop, otherwise you
> may get an async call in the same thread. Since this is an unsafe &
> minority & mostly unused feature; and it's impossible to distinguish
> reliably from anywhere but the calling app which is required -
> henceforth the unsafe/random-thread-foo thing needs to go away - all
> async callbacks must be processed in <whatever> thread that holds the
> GMainContext lock.
> 
> 	So - if you didn't understand a word of that - fine :-) life is good;
> the patch will make everything clear ;-)
> 
> 	Regards,
> 
> 		Michael.
> 
> _______________________________________________
> orbit-list mailing list
> orbit-list gnome org
> http://mail.gnome.org/mailman/listinfo/orbit-list