[PATCH 4/4] dlls/ntdll: Call try_recv inside sock_recv only if it is safe to do so.

Zebediah Figura (she/her) zfigura at codeweavers.com
Tue Jan 18 17:08:22 CST 2022


On 1/18/22 13:30, Jinoh Kang wrote:
> Otherwise, try_recv() call from sock_recv() may race against try_recv()
> call from async_recv_proc(), shuffling the packet order.
> 
> Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52401
> Signed-off-by: Jinoh Kang <jinoh.kang.kr at gmail.com>
> ---
>   dlls/ntdll/unix/socket.c | 38 ++++++++++++++++++-------------------
>   dlls/ws2_32/tests/sock.c |  8 ++++----
>   server/protocol.def      |  4 ++--
>   server/sock.c            | 41 ++++++++++++++++++++++++++++------------
>   4 files changed, 54 insertions(+), 37 deletions(-)

Despite the attempts to split 2/4 and 3/4 out of this patch, it's still 
doing two things at once. Namely, the optimization whereby recv_socket 
returns STATUS_ALERTED should not be part of this patch.

As I discussed in [1] it's not really clear to me that three server 
calls is significantly worse than two. It'd be nice to know that just 
removing the initial try_recv() call is really going to make programs 
worse if we're going to pursue it. I.e. personally I'd rather just leave 
it alone until we find a program that gets worse.

That aside, though, I'm not sure that adding a new select type is really 
the right way to go about this. One approach that occurs to me, which 
might end up being simpler, would be to return an apc_call_t, 
essentially as if the select request had been called immediately 
afterward. (In that case perhaps we should return STATUS_KERNEL_APC 
rather than STATUS_ALERTED).

[1] https://www.winehq.org/pipermail/wine-devel/2021-December/202825.html



More information about the wine-devel mailing list