[PATCH 01/10 v2] server: Introduced iosb struct for server-side IO_STATUS_BLOCK representation and use it in irp_call.

Sebastian Lackner sebastian at fds-team.de
Tue Oct 25 06:47:27 CDT 2016


2016-10-25 13:26 GMT+02:00 Jacek Caban <jacek at codeweavers.com>:
> On 25.10.2016 06:03, Sebastian Lackner wrote:
>> On 24.10.2016 15:46, Jacek Caban wrote:
>>> BTW, did you expect staging patches to be so much faster in overlapped
>>> case than plain Wine? I didn't look too deeply in the code, maybe there
>>> is some optimization, but that's a bit suspicious.
>> Thanks, these are exactly the stats I was looking for. I'm not aware of
>> any special optimizations, so not sure how Staging can be faster.
>> If you used a prebuilt Staging version with compiler optimization enabled
>> that could also be the reason.
>
> I should be more precise, sorry. In my tests I used plain Wine with
> staging named pipe patches applied (some trivial conflicts needed to be
> resolved AFAIR). I can try it other way if you think it would be valuable.

Hm, I am not sure what causes it then. I will probably do some more
investigations, but it shouldn't really block your patchset. It could
also be a side effect of using a different socket type (SOCK_SEQPACKET
vs SOCK_STREAM) for example.

>
>> BTW; I assume you are aware of it already, but your current
>> implementation
>> lacks handling of PIPE_NOWAIT, which is also implemented in the Staging
>> patchset.
>
> Yes, this patchset was intended to be as small as makes sense and
> PIPE_NOWAIT is not implemented in current Wine anyway. PIPE_NOWAIT
> should be easy to implement on top of my patches, preferably after
> patches for immediate read/write returns are in (that's one of mentioned
> optimization). I expect this to be very simple then.
>
> Thanks for the feedback.
>
> Best regards,
> Jacek



More information about the wine-devel mailing list