-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Sockets seemingly can't be read from and written to at the same time on windows #14233
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I believe this is because the socket is not created with
Simply adding the flag is insufficient to fix the problem, however, because So I think @ghost's solution of using |
A combination of sendto/recv from and WSA_FLAG_OVERLAPPED does indeed fix the issue. I'll do some more testing and submit a PR. Updated client test code below:
|
I've found a couple of approaches to this, looking for opinions.
This still means I have to change net.Stream, but I can leave them as windows.ReadFile and just pass 0 for the offset to trigger the overlapped IO code.
I've done some searching and there is a GetHandleType that just returns false for sockets, but not just for sockets. So getsockopt was the best method I could find. Unless someone can think of a better solution? This seems like the right approach to me, as someone on Windows would expect to be able to use posix.read on a handle they created with posix.socket. But the system call to do a handle check on each read/write just doesn't sit right. |
OK I think I have a solution. Buried within ntdef.h is: // So I'm going to prose we tag any file handle that is opened as a socket with a 1 in the lowest bit. Then we can use that bit to determine whether to use ReadFile of WSARecv in the posix functions and remove the special casing for Windows in the net.Stream struct. |
I didn't tag this as bug because it might be me doing something wrong, but I'm at the end of my rope here. Here's my client code:
And the server:
Expected behavior
The client shows "trying to read", then "wrote".
Actual behavior
On Windows, the client shows only "trying to read", never "wrote".
If I change the order of the threads so that the write happens before it starts trying to read, the write goes through. It's as if writes can't be done while another thread is trying to read from the same socket.
On Linux, it works as expected - the write goes through, even while the read is blocked.
I investigated the stdlib source and found that
net.Stream
'sReader
andWriter
implementations use genericReadFile
andWriteFile
syscalls, rather than socket-specific ones. I thought that might be the problem, so I tried modifying it to usesendto
andrecvfrom
instead, but the behavior was the same.I tried writing a similar program in Rust, provided below, and the problem didn't happen.
Version
0.10.0, also happens on 0.11.0-dev.1240+24b4e643f
The text was updated successfully, but these errors were encountered: