Re: Plans for gnome-vfs replacement
- From: mathieu lacage <Mathieu Lacage sophia inria fr>
- To: Alexander Larsson <alexl redhat com>
- Cc: Paolo Borelli <pborelli katamail com>, "gtk-devel-list gnome org" <gtk-devel-list gnome org>, Paolo Maggi <paolo gnome org>, "gnome-vfs-list gnome org" <gnome-vfs-list gnome org>
- Subject: Re: Plans for gnome-vfs replacement
- Date: Wed, 20 Sep 2006 14:30:21 +0200
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]