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