Re: GVfs status report

[nf2 <nf2 scheinwelt at>]

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