Re: gnome-vfs usage of GConf vs threads

[Michael Meeks <michael ximian com>]

On Mon, 2002-12-09 at 18:04, Alexander Larsson wrote:
> > 	And of course - this need only be a temporary solution, since I'm
> > planning to merge the ORBIT2_MT branch to HEAD for gnome-2-4 anyway
> > which (I assume) is where most development will happen for whatever we
> > do to gnome-vfs next.
> 
> gconf would need to be fixed too.

	Well - we'd certainly need to be able to decide what thread a callback
might happen in [ and when ], particularly if there is no mainloop
running in a thread, you prolly want incoming events to be processed in
a separate thread [ but only for some keys ;-].

> > 	The wonderful thing about threads is that finally - we can perhaps
> > start to convince people that adding this tool is a _really_ bad idea
> > :-) [ cf. some code I was reading today with a global 'i' variable - if
> > you can't locally scope your variables what chance have you of
> > understanding the complexities of locking ].
> 
> Of course, if they can't get locking right there are slim chances they can 
> get reentrancy right. :)

	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 ;-)

> Seriously, corba reentrancy needs to be fixed too before it can be used 
> from gnome-vfs. We can't start responding to nautilus metadata requests on 
> the gnome-vfs worker threads.

	You have a number of choices ( at least in Sebastian's impl. ) -
currently I've not looked at implementing the POA changes necessary -
only getting the client side right. The choices are per POA and
something like at least:

	* handle each request in a new thread - no re-enterancy
	* handle each request on a given object in a single thread
	* handle each request to the same poa in a different thread
	* handle each connection in a different thread.

	And of course the vanilla re-enterant model we're used to. My feeling
is that the 3rd option is perhaps the best for some gconf usage, and the
existing scheme fine for most things. Ultimately all event processing in
anything but 'each request in a new thread' is re-enterant -
necessarily.

	HTH,

		Michael.

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