Re: GVfs status report
- From: Alexander Larsson <alexl redhat com>
- To: nf2 <nf2 scheinwelt at>
- Cc: gnome-vfs-list gnome org
- Subject: Re: GVfs status report
- Date: Thu, 13 Sep 2007 16:47:55 +0200
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
] [Thread Prev