Re: gnome-vfs usage of GConf vs threads

[Michael Meeks <michael ximian com>]

Hi Alex,

On Tue, 2002-12-10 at 13:30, Alexander Larsson wrote:
> It's not that hard really.

	Sure - it's not;

> > 	Haha ;-) I think re-enterancy is a simpler tool than threading - as you
> > know both schemes scatter the code with re-enterancy hazards, a pure
> > re-enterant approach simply ensures those are at well defined points ;-)
> 
> This is where we have a fundamental disagreement. Threads are hard, yes, 
> but they are manageable. There exists lots of books on the subject and 
> people learn about it in school. Strategies for handling locking and 
> avoiding deadlocks are well known and locking can be well encapsulated 
> most of the time.
> 
> Contrast this to re-entrancy.

	I just see such a lack of contrast ;-) it seems to me that they are
essentially identical, but instead of random context switches - you have
a more controlled control flow switch at well defined points. It seems
to me almost equivalent. 

	It's certainly true that by holding a lock over a CORBA method
invocation you can be sure that the data is still consistant when you
get back - and thus you have more control over serializing the
processing of requests. But - this just switches the problem to the
client instead of the server with deadlocks turning up at unexpected
places.

	Again - you still have to know that any given C call you make could
trigger an incoming call that could stomp on your data and/or deadlock
you, necessitating expensive lock/unlocks around methods in the same
way. If you're going to do expensive lock/unlocks around invocations (I
believe any local/remote distinction has no bearing on the issue) - you
might as well hold refs on what you're working on instead ;-)

	Anyway - I guess we need a ORBit_deadlock_push / pop method somewhere
to stop the processing of incoming calls; although you can fairly easily
replicate this with:

	PortableServer_POAManager_hold_requests (
		bonobo_poa_manager (), FALSE, &ev);

	.. do some blocking CORBA call ...

	PortableServer_POAManager_activate (
		bonobo_poa_manager (), &ev);

	Where the incoming invocations get processed on the 'activate' (ie.
unlock).

	Hmm,

		Michael.

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