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 select binding to sockets on Windows.

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 select is a thin wrapper around the underlying select call which in Winsock only supports socket handles. When Unix.select is passed a mixture of handles, we use a (necessarily) complicated system to wait on all the different classes of handle separately and then emulate the result - either something is wrong in there or, more likely, some extra work is needed to emulate level triggering over edge triggering. However, there's a fast path if all the handles are sockets, when we just use the underlying Winsock select call. This fast path is what is making this bug report quite so subtle.