On 28.02.2017 20:46, Sebastian Lackner wrote:
On 28.02.2017 18:10, Jacek Caban wrote:
On 28.02.2017 16:44, Sebastian Lackner wrote:
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.
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.
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.
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.
The point is, named pipe code needs just small changes for such optimization, no refactoring. I hope that addresses your concerns.
Jacek
[1] https://www.winehq.org/pipermail/wine-devel/2016-October/115071.html