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
Unix.select with a mix of sockets and non-sockets is not level triggered on Windows #7665
Comments
Comment author: toots I can confirm that, too. Seen here with a mixture of pipe and network socket. Attached is a minimal script reproducing my case. It happens in a complex scheduling context (liquidsoap) and would be great to see fixed.. Tested with versions: 4.01 & 4.07 so it's been around for a while. |
Comment author: toots I believe this is the relevant documentation about the underlying call: "The FD_WRITE network event is handled slightly differently. An FD_WRITE network event is recorded when a socket is first connected with a call to the connect, ConnectEx, WSAConnect, WSAConnectByList, or WSAConnectByName function or when a socket is accepted with accept, AcceptEx, or WSAAccept function and then after a send fails with WSAEWOULDBLOCK and buffer space becomes available. Therefore, an application can assume that sends are possible starting from the first FD_WRITE network event setting and lasting until a send returns WSAEWOULDBLOCK. After such a failure the application will find out that sends are again possible when an FD_WRITE network event is recorded and the associated event object is set." |
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
could this be reopened please? |
This looks like something that needs Windows expertise. (cc @nojb, @dra27, @MisterDA). From the outside it's not clear how to provide the expected behavior on top of a function behaving as described. It looks like Python restricts its own |
Just to nudge this a tiny bit further: @gasche, I expect that Python does what we used to prior to OCaml 3.11 which is that |
Original bug ID: 7665
Reporter: gabelevi
Status: new
Resolution: open
Priority: normal
Severity: minor
Platform: win32
OS: Windows 10 Enterprise
OS Version: 1511
Version: 4.03.0
Category: platform support (windows, cross-compilation, etc)
Monitored by: @ygrek @dbuenzli
Bug description
I'm using 4.03.0+mingw64 https://fdopen.github.io/opam-repository-mingw/2016/05/03/ocaml_4_03/
Unix.select should be "level triggered". That is, as long as a fd is ready, it should be returned. This is opposed to being "edge triggered", where the fd would only be returned when it first becomes ready.
On Windows, Unix.select with a mixture of sockets and non-sockets does not return all of the ready fds consistently. The first call behaves correctly, but subsequent calls don't.
Steps to reproduce
I uploaded a script which demonstrates the problem, by selecting both a socket and stdin. For some reason, Unix.select stops reporting the socket as being ready. I ran it on cygwin
$ echo "hello" | ocaml C:/cygwin64/home/glevi/.opam/4.03.0+mingw64c/lib/ocaml/unix.cma testA.ml
Set up socket
Socket is not yet connected, so only stdin should be ready
stdin is ready
sock is not ready
Connected to socket
Now they both should be ready
stdin is ready
sock is ready
But if we call select again we hit the bug
stdin is ready
sock is not ready
And it repros if we call again
stdin is ready
sock is not ready
Individually stdin is readable: true
Individually sock is readable: true
But together it is still buggy
stdin is ready
sock is not ready
File attachments
The text was updated successfully, but these errors were encountered: