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.
> and, does it really make sense to have individual GMainContexts per
> async operations?
> since you have a statefull object already, wouldn't something
> like this be better:
>
> void g_input_stream_set_async_context (GInputStream *stream,
> GMainContext *context);
> void g_input_stream_async_read (GInputStream *stream,
> uint8 *buffer,
> ...);
> i.e. here you'd essentially force users to set_async_context() before
> any of the g_input_stream_async_*() ops could be called.
Yes. This seems like a nicer approach. I had a single read method, but
then two wrappers (_read and _read_full) for it so that you didn't
alwyas have to pass the NULL context.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
[EMAIL PROTECTED] [EMAIL PROTECTED]
He's a suicidal coffee-fuelled jungle king possessed of the uncanny powers of
an insect. She's a radical gypsy socialite with an evil twin sister. They
fight crime!
_______________________________________________
gnome-vfs-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
