https://bugs.winehq.org/show_bug.cgi?id=10648
--- Comment #7 from Jinoh Kang jinoh.kang.kr@gmail.com --- (In reply to Zebediah Figura from comment #6)
(In reply to Jinoh Kang from comment #5)
Requesting to reopen the ticket.
The gRPC library relies on the all-or-none behaviour of nonblocking send() on Winsock. All applications relying on gRPC thus fails to transmit RPC packets properly.
It's possible to patch gRPC instead [1] so that it properly handles partial writes, but it is not always feasible in proprietary software applications.
I've reopened, but fixing applications is preferable if at all possible. It's not clear that any other applications actually care about short write behaviour.
Possible directions for the fix include:
- In sock_send(), test if it's possible to actually send the full stream
data before calling send().
How?
Heuristics. Actually it would require *both* remedies in order for the final solution to be plausible at all.
- On partial write, queue up the rest of the buffer and report success.
This seems to me like the only option feasible right now, although it's obviously far from ideal.
Combined with heuristics above, I think this won't happen that much frequently in practice.
Of course, we could also try to introduce an extra socket option or flag into the kernel.
Linux maybe, but Darwin...