Re: GVfs status report

[Alexander Larsson <alexl redhat com>]

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). 

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?

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.