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

[Michael Meeks <michael ximian com>]

Hi Alex,

On Tue, 2002-12-10 at 16:30, Alexander Larsson wrote:
> With re-entrancy you can never say. "this function is safe to call with 
> lock foo", because you have no control over what else will be called. 
> Possibly some function that takes lock foo, which will deadlock (with 
> threads that thread would just block until the lock is released). 

	Doh - you're entirely right. I'm missing the larger picture by thinking
of simple callback cases.

> With CORBA reentrancy there are no way to set up rules such that if you 
> follow them you avoid deadlocking when holding a lock over a CORBA call. 

	But then again; thread per call sounds horribly expensive resource
wise; hmm. Quite possibly a magic queueing API would be better.

> How would you make it safe if we are working in a single-threaded 
> environment where corba calls reenter (and you have no control of other 
> corba calls, like when you're writing a library/component)?
> 
> The threaded case is surely complicated, but the re-entering one has no 
> solution.

	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.

> Something like that would be good. Of course, this can cause trouble if 
> another thread uses that poa. I can hardly e.g. stop all processing for 
> bonobo_poa_manager() from a gnome-vfs thread. So I have to have my own POA
> instance to do that. 

	Sure - we'll have to expand the POA stuff in libbonobo anyway - and
make it threadsafe (which should be fairly easy) since thread policies
are per poa.

	Anyway - thanks for setting me straight; it's all the more imperative
that we have a working threaded ORB soon then I suppose.

	Regards,

		Michael.

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