Alexander Larsson wrote: > On Wed, 2007-09-12 at 13:10 +0200, nf2 wrote: > >> Alexander Larsson wrote: >> >> >>> You don't need a session object for that. Other solutions is to pass it >>> in the context to each async operation, or to have a thread-local >>> setting for the main loop to use. >>> >>> However, currently this is not supported, as it doesn't seem very common >>> to use async i/o in a separate thread. UI apps use async i/o mainly to >>> avoid blocking the main thread, and rarely on threads, so we decided to >>> not support it. (Well, you can initiate async i/o on a thread, but the >>> callback will be on the main thread.) We do however support using sync >>> i/o on threads. >>> >>> >> 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? > There is really no sane way to share connections between threads, as > only one thread can be reading the messages. > > >> i just believe that a standard file-management api like gio should not >> do things like storing state in global variables or depend on a default >> main loop context. it should support "not so common" uses cases. it's ok >> to have a convenience api which initializes a default session object, >> but i think there should be another "professional" api behind that... >> > > 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. in my libfusi i use a second gmain context to "synchronize" a sub-system which has been designed in an async way - to block the GUI context (actually to be able to provide a synchronous and async mount operation, relying on the same async code). btw, i also found it annoying that GIOChannels only operate on the default context. > Async I/O is typically used to avoid using threads (although it is often > implemented using threads). Combining async i/o and threads sounds like > a horrendous idea. You get the worst of both. All the locking issues > with threads, and the hard-to-use aspects of async i/o. > > really? you could have two threads communicating with idle sources for instance. 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. norbert _______________________________________________ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
