Re: GVfs status report

[Alexander Larsson <alexl redhat com>]

On Thu, 2007-09-13 at 11:02 +0200, nf2 wrote:
> Alexander Larsson wrote:
> >> and what about the gvfs dbus connections? they also need a session 
> >> object to live in. even for sync io in a separate thread: can you use 
> >> the same dbus connections like in the main thread?
> >>     
> >
> > What about it? It works fine. With the current system there is a single
> > one for async i/o, and per-thread ones for sync i/o. One could add
> > per-thread ones for async i/o (it had that once, but I removed it). 
> >   
> 
> i see. so you have a per-thread pool of dbus connections?

One connection per thread per mountpoint for sync ops. No need for
multiple ones since there can be at most one message outstanding. 

> > I don't agree. I think nobody would use this, and there will be more
> > than one horribly complicated bug caused by it. Can you come up with an
> > sane example usecase where you want to do async i/o in a worker thread?
> >   
> 
> i think there are situations where a second gmain context is useful:
> 
> using async operations which recurse the mainloop (pseudo blocking) in a 
> thread - for instance for downloading a complete file like 
> KIO::NetAccess. or using a library with async design (internally using 
> gio) in a thread.

Well, in this case the library (gio) does have an sync design, so there
is no need to emulate a sync call using a mainloop.

The initial multi-context work in gio was done by passing a GMainContext
to all the async ops. This is bloating the API way to much for normal
use. However, it could be extended (at a later point even) with a way to
set the default i/o context on a per thread basis. (Or even for all uses
of the default context?)

I don't think its especially important though, and it certainly does
make implementations a lot harder. (For instance, the
multiple-async-dbus-connections code was a pain).

> however - i guess for 90% of the use cases you are right. i just thought 
> that a universal file io-library, which competes with open, opendir and 
> stat should be quite low-level and not make decisions about the default 
> context or the main thread (KIO and Gnome-VFS have been designed too 
> high level - and that's IMHO their crucial mistake). i believe it's good 
> that glib allows to have different gmain contexts and doesn't use global 
> variables extensively. i would expect that a file-io interface which 
> comes with glib is fitting into this model.

I belive the real number i far larger than 90%, more like very near to
100%.