[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Re: [PATCH 01/10 v2] server: Introduced iosb struct for server-side IO_STATUS_BLOCK representation a
From:       Sebastian Lackner <sebastian () fds-team ! de>
Date:       2016-10-25 11:47:27
Message-ID: CAH3W0hVz2JObV3Lg4-U7VF6iznazo9=wJQaaE8ek0gLToA=tKw () mail ! gmail ! com
[Download RAW message or body]

2016-10-25 13:26 GMT+02:00 Jacek Caban <jacek@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



[prev in list] [next in list] [prev in thread] [next in thread]