Re: Some comments about GVFS

[Alexander Larsson <alexl redhat com>]

On Mon, 2007-05-07 at 14:08 -0500, Hans Petter Jansson wrote:
> On Mon, 2007-05-07 at 09:24 +0200, Alexander Larsson wrote:
> > On Fri, 2007-05-04 at 17:52 +0200, Benjamin Otte wrote:
> 
> > > Yeah, I missed those implementations as I was only grepping for
> > > GMainContext which you don't use.
> > > I think it's a good idea to make the main context customizable so gvfs
> > > can be used from other threads.
> 
> > The api used to have this, but there was a lot of overhead code carrying
> > this around and adding it to the parameter list of all functions, and I
> > thought there would be very very few people using it, so i killed it.
> > Maybe we should discuss reverting that decision...
> 
> In Flow, I keep a GMainContext associated with each GThread. The API
> user can set his own GMainContext for each thread, but for simplicity it
> can only be set once, before any other Flow calls are made in that
> thread.

So, an async operation inherits the main context from the thread that
started it. Its nice that you don't have to fill up the API with context
arguments, but it also seems to make it a bit more complicated to handle
multiple contexts. For instance, you can't have one thread starting
async operations that run on multiple context. But perhaps this is not
so important? What do users of multiple contexts need?

> I find that this allows for a lot of flexibility without adding much
> code complexity at all:
> 
> 1) The default GMainContext for the main thread is the default GLib
> GMainContext. This allows sync operations to spin the main loop (so if
> you have a program that lends itself to that design, you can process
> redraws and UI operations while in a sync I/O call).

Danger will robinson! This sounds like a recipe for disaster. Sync calls
calling back into the mainloop can easily cause reentrancy, and we're
back in bonobo hell again. I.E. call any flow function, and you could
reenter (via a mainloop callback) into any random code in the app which
could modify the state of the code that was calling flow. (And if that
state is in a partially changed state things can go very bad.)

Its also very problematic wrt locking. We have the same problem with
authentication callbacks in gnome-vfs. These are called back from any
sync operation when authentication is needed, and often requires UI to
finish, and thus a mainloop. However, since it is doing UI it needs to
take the gdk lock, but that deadlocks if the gdk lock was taken when the
sync call was called. In the case of flow, what if you get an idle
callback inside a sync call, and the idle callback (correctly) takes the
gdk lock...

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a fiendish skateboarding cyborg She's a mistrustful motormouth angel 
living on borrowed time. They fight crime!