Re: gnome-vfs usage of GConf vs threads

[Alexander Larsson <alexl redhat com>]

On 10 Dec 2002, Michael Meeks wrote:

> 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 ;-].

It's not that hard really.

You make each GConfClient separate from the others with its own (possibly 
virtual) connection to the gconf server that isn't affected by anything 
else (i.e. no reentrancy). Contention on configuration data should be low, 
so a reader-writer lock taken on all GConfClient calls should work fine. 
Getting from the local cache takes a read lock, cache misses and config 
settings take a write lock. [Updating from the server on a cache miss 
better not reenter or we'd be in deadlock heaven]

Slightly harder is getting changed callbacks. The way I see it you have to 
allow two sorts of callbacks: callback on new thread and callback on a
mainloop. When you register a thread callback you just give a function 
pointer that will be called on a newly created thread (this is useful for 
http-method use). For a mainloop callback you have to specify a mainloop 
that the callback will be done on. Then whatever thread runs the mainloop 
in question will be the one that gets the callback (needs a mainloop that 
runs, this will typically be the gtk mainloop in a normal gui app).

The implementation of the event callbacks can be done in two ways, and 
both probably need to be implemented so you can pick the GConfClient type 
that best fits your app. One implementation uses a thread that does all 
the communication with the gconf server, and the other one installs 
watches on a mainloop. Both implementations can do both types of 
callbacks, one requires a mainloop that runs most of the time but won't 
need to use threads, the other one is useful if you don't have a 
mainloop, or can't rely on it being active all the time.

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

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 bet very few people are aware that any 
time you call a bonobo function that does a corba call any of your corba 
implementations can be executed during your call. This means you have to 
make sure your data is in a sane state before each bonobo call and re-read 
all locally cached data on return. You can't even rely on the fact that 
the objects you are dealing with still exists, as they may have been 
destroyed during the call.

Gtk+ has this issue with signal emissions (since the signal handler may, 
and typically will, call any function on the widget emitting the signal).
It is only thanks to tireless work by Tim "reentrancy" Janik that it works 
at all. Gtk+ used to crash a lot in random ways until he fixed up all the 
places that do signal emissions to leave the widget in a known condition. 
Very often this requires ref:ing objects before the signal emission so 
that they won't die during the emission. Sometimes this isn't even 
possible with ORBit because bonobo_object_ref() is a function that may 
reenter.
 
> > 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.

Yes. It is unfortunate that either full threading of each call or 
re-entrancy is needed for Corba. That just strenghtens my view that we 
should have made our COM implementation in-process only and have 
the out-of-process API more explicitly asynchronous and much less fine 
grained. 

But we had this discussion a long time ago, and what we have now is what 
we got, for better or for worse. If we add thread policies to POAs and 
a way to mark functions to not reenter it will probably be enough to 
handle what we have to handle.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a scrappy bohemian ex-con haunted by memories of 'Nam. She's an elegant 
mute mermaid from a different time and place. They fight crime!