Michael McCormack mccormac@aals27.alcatel.com.au writes:
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.
Reducing the number of server calls but making them more expensive is not necessarily a gain. Show me the numbers...
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.
I'm not sure it's a good idea, particularly if we want to support signals (which I think would be a good thing since it allows getting rid of the service thread).
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)
You'll probably still need a server call to find out about file locks at some point. And again you'll get in trouble if you want to support signals.