<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 28.02.2017 20:46, Sebastian Lackner
wrote:<br>
</div>
<blockquote
cite="mid:46b0d7cc-5cad-1eb7-9e42-c5323ea3d4c3@fds-team.de"
type="cite">
<pre wrap="">On 28.02.2017 18:10, Jacek Caban wrote:
</pre>
<blockquote type="cite" style="color: #000000;">
<pre wrap="">On 28.02.2017 16:44, Sebastian Lackner wrote:
</pre>
<blockquote type="cite" style="color: #000000;">
<pre wrap="">Well, there are also situations where it would be relatively easy to avoid
the roundtrip. We could return immediately at least when no events, APCs or
completions are involved, right? Since this is the most common situation it
might still be worth the effort.
</pre>
</blockquote>
<pre wrap="">If event is not passed, we still need to signal object itself. Thinking
about it some more, I guess we could just signal object it before
returning for non-overlapped operations returning immediately. It
wouldn't be exactly right, but it can't be used for synchronization
reliably in this case anyway.
Another thing is that we currently don't know if there is user APC until
APC_ASYNC_IO returns, but that can be fixed.
Since it's just an optimization, can we process with the patch itself
first? I'm happy to optimize that, but I find it hard to agree that an
optimization should block inclusion of patches targeted at correctness.
</pre>
</blockquote>
<pre wrap="">I'm not saying that it should block anything, I will leave the design decision
up to Alexandre. Nevertheless, I think it certainly makes sense to discuss
about such aspects in advance. Depending on the solution used it might also
require refactoring of this patch, which is easier to do before it was accepted.
</pre>
</blockquote>
<p><br>
</p>
<p>I drafted an optimization discussed in this thread. It's just a
proof-of-concept. A better implementation will store user APCs on
server side when the async is created and I'd consider moving
handling of returned data and wait handle out of fd-specific ops.
I ran it on my benchmark from last year [1] and it was 2 times
slower than what I called "plain wine+msgmode
patchset+optimizations". It's expected, since with that we need
two server calls (that one needed one). Going down to one server
round-trip for simple cases is easy with that and should give
about equal results.</p>
<p><br>
</p>
<p>The point is, named pipe code needs just small changes for such
optimization, no refactoring. I hope that addresses your concerns.</p>
<p><br>
</p>
<p>Jacek</p>
<p><br>
</p>
<p>[1]
<a class="moz-txt-link-freetext" href="https://www.winehq.org/pipermail/wine-devel/2016-October/115071.html">https://www.winehq.org/pipermail/wine-devel/2016-October/115071.html</a><br>
</p>
</body>
</html>