Re: RFC: client side implementation of async I/O

[Alexandre Julliard]

Michael McCormack <mccormac(a)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(a)winehq.com

RFC: client side implementation of async I/O

[Michael McCormack]

Hi Alexandre,

i have rewritten my patch for the latest wine release. The main changes from
the previous are that it only checks overlapped operations in
WaitForMultipleObjectswEx, and it now uses SetEvent to end the operation.
(courtesy of your new servercall architecture). I have done a simple
benchmark. The results of the benchmark on my Pii350 and an internal modem 
are as follows:

Wine 2001/03/05 vanilla + async-fix.diff:
average write time for "AT" command:  675 usec
average read time for response:  634 usec

Wine 2001/03/05 + client-async3.diff:
average write time for "AT" command: 362 usec
average read time for response: 322 usec

The times in themselves are pretty meaningless, but it is the same program,
under the same conditions.

The patches and program i used are included.

Mike

On Tue, 6 Mar 2001, Alexandre Julliard wrote:
> Michael McCormack <mccormac(a)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...

-- 

__________________________________________________________________
mailto:Michael.McCormack(a)alcatel.com.au  phone: [phone] (h)
                                                ([phone] (m)