Re: Plans for gnome-vfs replacement



On Wed, 2006-09-20 at 13:52 +0200, Alexander Larsson wrote:

> > 1) Don't you think it might make sense to also add an io priority arg to
> > the sync functions ?
> 
> Possibly. It wouldn't really be implementable for normal local files,
> but could help for e.g. vfs streams from the daemon. It seems much more
> useful for async operations though, since its generally only when you
> use those that you get multiple outstanding operations at the same time.

agreed. I was merely wondering.

> 
> > 2) What is the signature of GDestroyNotify ?
> 
> Its already in gtypes.h:
> typedef void            (*GDestroyNotify)       (gpointer       data);

ah. I forgot about this. Don't you think it might make sense for ease of
use to add a void *buffer arg and a GOutputStream * arg to the destroy
notification ?

> Parallel opens for write of a file have implementation defined
> behaviour. (Things will depend a lot on the exact timing.)
> 
> What I mean by async opens is that if I open a non-existing file for
> reading, the open will succeed, giving me a input stream that will cause
> a no-such-file error when you start reading from it. The alternative
> would be that the open call blocks, doing i/o to see if the open
> succeeds. That would be bad if you were opening the file for async use.
> If you do async read on the new input stream the first async read will
> also implicitly do an async open.

My gut feeling is that moving error reporting for the open call to the
read call is wrong but I have not been able to come up with an
interesting counter-example.

> As to barriers and stuff, I've taken the simple route. Once a stream is
> created you can only have one outstanding request (be it sync or async),
> and any other operation during this time will return
> G_VFS_ERROR_PENDING. Many streams (take a ftp put for instance) just
> doesn't support multiple requests.

I see. So it would be up to the application developer to create his own
queue of requests. 

thank you for your detailed answer,
Mathieu




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]