Re: GVfs status report

[nf2 <nf2 scheinwelt at>]

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