> My worry is that somehow a program has a fd that refers to both a file and a socket. But I agree that changing the API is not a great option either.

Well, when I read again my patch and played with it, I saw that it has different issues:

- a Windows socket handle is not an int, but a pointer: Python SOCKET_T type should be used instead

- when send() fails, we should reuse the code from socketmodule.c to raise an exception: we may need to check GetLastError() on Windows

I rewrote my patch to add a new function signal.set_wakeup_socket() instead of trying to guess if the file descriptor is a socket or a file. I adopted a similar approach in the PEP 446 with os.set_inheritable() and os.set_handle_inheritable() for the same reason: support sockets on Windows, socket.socket.set_inheritable() uses os.set_inheritable() on UNIX and os.set_handle_inheritable() on Windows.

signal.set_wakeup_socket() now takes a socket.socket object and returns the previous socket object (or None).

In the new patch, signal.set_wakeup_fd() and Py_SetWakeupFd() function are unchanged, which is more safer regarding to backward compatibility!

The first call to signal.set_wakeup_socket() imports the _socket module.

The Visual Studio still needs to be modified to add the dependency to the WinSock library ("ws2_32.lib"), just for the send() function.