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%. _______________________________________________ gnome-vfs-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
