Hello All,
I am trying to run a Python gRPC application in WINE.
It turns out the gRPC Windows binding uses WSASend which first tries the "blocking" variant on a overlapped socket.
Based on the code, the EXPECTED behaviour is that WSASend is atomic: It either sends nothing and reports WSAEWOULDBLOCK, or it sends everything and reports SUCCESS.
The behaviour in WINE is: It sends upto the TCP Congestion window, and I haven't seen it report WSAEWOULDBLOCK. (WSASend() returns 0)
Anyone observed this before? How do other programs handle this?
I reported the same issue at the gRPC group https://groups.google.com/g/grpc-io/c/-RzRZ867jy0
Best regards,
Ruud
On 1/6/22 08:40, Ruud Schramp wrote:
Hello All,
I am trying to run a Python gRPC application in WINE.
It turns out the gRPC Windows binding uses WSASend which first tries the "blocking" variant on a overlapped socket.
Based on the code, the EXPECTED behaviour is that WSASend is atomic: It either sends nothing and reports WSAEWOULDBLOCK, or it sends everything and reports SUCCESS.
The behaviour in WINE is: It sends upto the TCP Congestion window, and I haven't seen it report WSAEWOULDBLOCK. (WSASend() returns 0)
Actually this isn't so much Wine's behaviour as it is the behaviour of the host OS. We simply pass through the same parameters to the host send().
It turns out to be more than a little difficult to provide Windows compatibility here. We would probably need to perform some manual buffering in wineserver.
Anyone observed this before? How do other programs handle this?
Usually programs don't care. That is, they follow the POSIX documentation, and correctly handle short writes. It would be ideal if gRPC can do this as well.
I reported the same issue at the gRPC group https://groups.google.com/g/grpc-io/c/-RzRZ867jy0
Best regards,
Ruud
-
Ruud Schramp -
Zebediah Figura (she/her)