[PATCH 4/5] server: Added server side mamed pipe read and write implementation and use it for message mode pipes.

[Sebastian Lackner]

On 13.03.2017 13:31, Jacek Caban wrote:
> 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
> 
> 

Thanks for sharing the draft patch. All of the ideas you mentioned
sound reasonable, but if you already know how to solve these problems,
I am not sure why you insist on merging your named pipe implementation
first. The goal should be to keep the risk of regressions (this also
includes performance regressions - or weird issues because USR1
signals arrive on other threads, possibly interrupting libraries
which cannot deal with it) as small as possible. Imho it would be
preferred to fix the limitations first, then adding the named pipe
implementation.

So far I'm also not sure yet if this separate async_complete
wineserver call really is the best approach. What about just using the
existing wait mechanism? Either read/write immediately starts a wait
and the ntdll side would look similar to server_select().
Alternatively it would also be sufficient to block USR1 signals until
ntdll has reached NtWaitForSingleObject. If you decide to add such a
flag, it could probably also be reused to fix another bug.

[@ Alexandre: Do you think those concerns are valid, or do you think
the patches would be acceptable despite the problems?]

Best regards,
Sebastian