Alexander Larsson wrote: > On Wed, 2007-09-12 at 11:05 +0200, nf2 wrote: > >> Alexander Larsson wrote: >> >>> On Tue, 2007-09-11 at 18:55 +0200, nf2 wrote: >>> >>> >> another thing: gio doesn't have a "session object" - thus you cannot >> initialize it with a different main loop context - when using it in a >> worker thread for instance... >> > > 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? 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... perhaps the session object could be passed to the vtable calls in GFileIface... just some thougths, never mind... cheers, norbert _______________________________________________ gnome-vfs-list mailing list gnome-vfs-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
