Re: gnome-vfs usage of GConf vs threads - doh

[Michael Meeks <michael ximian com>]

Hi Alex,

On Wed, 2002-12-11 at 09:44, Alexander Larsson wrote:
> Yes. I'm not actually proposing using thread per call always. That would 
> be way to expensive and complicated. :) It has its uses though, so it 
> should be allowed.

	Sure - I too am looking forward to the new threading / locking code,
which should be nice for gnome-vfs generally too.

> > 	Not at all - there is a trivial solution; copy the list and/or
> > filter/update before you start doing your calls - clearly then (if
> > you're unreffing) you own a list of references; if you're not reffing -
> > you can at least hold a local CORBA_Object ref which involves no
> > roundtrip, and you're safe.
> 
> Hmmm. I'm not sure here. I thought it was like this, but I may be 
> misguided:
> 
> If item is a BonoboObject you can't safely ref it, because 
> bonobo_object_ref() is a reentrancy point as well. If bonobo_object_ref() 
> could be made a pure local call that would increase the "local refcount" 
> of the object reference it would work, but this is not possible due to the 
> fact that CORBA doesn't track object reference passing.

	bonobo_object_ref is a local call; certainly Bonobo_Unknown_ref may
well re-enter, but mostly you don't need to hold a remote ref over an
operation.

	Instead you typically do a local CORBA_Object_duplicate on the list of
references - ( a local call, that can throw no exception, just pass a
NULL ev ) - and then you're completely insulated from the original list,
and you can safely invoke methods / unref the local handle. Of course -
the remote object may be dead by that stage but that will result in
particularly bad effects.

> Are you saying you can ref a CORBA object with a guarantee of no 
> roundtrip?

	Sure - due to the joy of having about 15 different types of ref and
ways to take them ;-) it's possible to do a pure local ref on the
immediate CORBA handle - which is what we do around the place in exactly
this case.

> Yes. A lot of APIs (such as bonobo-activation and GConf) need to be 
> extended so that you can pass in a POA to use.

	I imagine for GConf it'd be nicer to hide that internally so as not to
pollute the API with CORBA-ness, and more simply expose the per thread
event handling aspect of it by expanding the API slightly.

	Regards,

		Michael.

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