Michael McCormack mccormac@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.
Alexandre Julliard wrote:
Michael McCormack mccormac@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.
IMHO the path to optimize is not async I/O in general, but async I/O through completion ports. This is the preferred method for doing high performance I/O under NT, I think.
And it might be easier to optimize because it doesn't focus on async actions visible from userspace; the main way the user code knows the async I/O is done there is by polling the completion port.
cf. http://www.kegel.com/c10k.html - Dan
Hi Alexandre,
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 changes.
Mike
On Mon, 5 Mar 2001, Alexandre Julliard wrote:
Michael McCormack mccormac@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.
-
Alexandre Julliard -
Dan Kegel -
Michael McCormack