RFC: client side implementation of async I/O

[Alexandre Julliard]

Michael McCormack <mccormac at 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.

-- 
Alexandre Julliard
julliard at winehq.com