A common VFS and a Common conf-system [Part II]

Alexander Larsson alexl at redhat.com
Thu Mar 3 11:00:22 EET 2005


On Wed, 2005-03-02 at 21:21 -0500, Sean Middleditch wrote:
> >
> >The problem is, that there might be lots of third party libraries which 
> >don't support async io.
> 
> It can be worked around on a case-by-case basis.
> 
> If SMB does need a separate thread for each connection, that can be
> done, and it can be completely hidden as an implementation detail of the
> backend.  It's frustrating that that might have to be the case, but it
> doesn't really affect the API or other backends at all.
> 
> If many/most backends need such a thing, then I guess threaded will be a
> necessary.  We're way far away from even being at the point where this
> matters, though - I'm right now concerned about the *application* API,
> not the internal implementation of the daemon or its backends.

You need threads or external processes for file:/// too, otherwise any
access to a NFS mount where the server is down hangs all I/O in the
desktop. Even if the NFS mount isn't totally down you can't do async i/o
on unix files, which means it'll block the rest of the vfs while doing
I/O.

I guess you might be able to use posix aio, but I don't think thats very
portable yet, nor does it support stat or readdir. (Does it still use
threads on linux?)

Some other issues:

You have to do authentication callbacks in the process doing the actual
i/o request. Otherwise things like gnome-keyring that depend on which
binary did the request to decide access rights won't work.

Authentication caching is a very complicated issue. When do you cache?
How long do you cache? Is the cache shared between apps (and how does
this affect security vs ease of use)? How do you log in as someone else
when you've already logged in?

One thing that makes authentication caching is the connectionless model
that e.g. gnome-vfs has. We don't know that there is an "active
connection" to some ftp server (say, nautilus is displaying it), so we
can't tie cache lifetimes to a connection. On the other hand, we likely
want to reuse the connection nautilus uses in e.g. gedit if we click on
a text file in the nautilus window, so we can't tie the connection only
to nautilus. I think you'd want a higher level object above the file
access operations, but slightly less than a full connection object.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's an obese voodoo dwarf on the wrong side of the law. She's a sarcastic 
Bolivian traffic cop from Mars. They fight crime! 




More information about the xdg mailing list