RFC: client side implementation of async I/O
mccormac at aals27.alcatel.com.au
Tue Mar 6 04:32:47 CST 2001
The patch can be further optimised, for example by keeping active asyncs in a
seperate list from inactive asyncs. i think it is more efficient because the
number of server calls and context switches is reduced.
What i'm more interested in is whether having waiting clients running
concurrently with wineserver and those clients waking themselves from wait is
a good idea.
Similarly, we could create a client side file handle cache that is alerted by
the wineserver when it becomes invalid. Before each fd is used, the cache
implementation would poll on the wineserver communication fd to confirm the
cache is valid, which would further improve the speed of file I/O. (a single
poll vs. a full server call)
i'm not using CVS so i'll have to wait until your next release to see the new
On Mon, 5 Mar 2001, Alexandre Julliard wrote:
> Michael McCormack <mccormac at aals27.alcatel.com.au> writes:
> > This patch moves responsibility for asynchronous I/O to the client process.
> > i'm posting it to wine-devel because i want to know what other developers here
> > think about the technique i've used to make this work...
> Your approach is not going to work with the latest changes I made to
> the server. The good news is that the changes I'm making are in part
> to allow making server calls in signal handlers, so when this works
> you should be able to use SIGIO to do async IO.
> > i think this implementation is more efficient, as it makes fewer server calls
> > and duplicates fewer file descriptors, while maintaining correctness.
> It's not clear to me that it is more efficient; it seems it will do a
> lot more work on every single server call if an async IO is
> pending. Of course the only way to tell is to run benchmarks.
mailto:Michael.McCormack at alcatel.com.au phone: (+8232) 667 0425 (h)
(+8211) 430 0425 (m)
More information about the wine-devel