On Mon, 2006-09-25 at 13:14 +0200, Alexander Larsson wrote:
> On Mon, 2006-09-25 at 11:40 +0200, Tim Janik wrote:
> > hm, in your initial proposal, you said that apps don't currently have
> > control
> > over whether they want to use/care about threading or not. so, are you
> > planning for a way to use the GVFS API without threading under the hood?
> > then, emulation of the above asny calls would be implemented in terms of
> > IO handlers attached to the provided GMainContext *context?
> Its an unfortunate fact of life that unix doesn't support asynchronous
> I/O for local files. I.E. a select on a local file *always* returns that
> it is readable, but it might still block when you call read() while
> reading the data from the disk. So, unless the OS has a good
> implementation of posix async i/o (which e.g. Linux doesn't) the only
> way we can get true async local file i/o is using threads.
>
> The way I had planned this was to always use true async i/o when talking
> to the vfs daemon via sockets (easy), but implement local async i/o
> using threads. If glib threads are not initialized we'd just fall back
> to doing blocking "async" calls.
You could use AIO on Linux and the equivalent on BSD, if you think it's
worth the effort. Flow will have an AIO-based implementation eventually.
--
Hans Petter
"...you cut a piece, and as you're taking it off of the fork the
main piece of the filet may be floating up out of the plate, but
you stab it with your fork and put it back down in, and if you
do it carefully, the surface tension of the gravy will keep it
in place."
- Russell Schweickart
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
