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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
