STINNER Victor added the comment: Windows only supports non-blocking mode for sockets. IMO we should only support sockets on Windows. I opened the issue #22042 which proposes to change signal.set_wakeup_fd(fd) to automatically make the file descriptor non-blocking. I cannot implement it on Windows because files cannot be configured to non-blocking mode.
I have an API design issue. Choices: (A) On UNIX, signal.set_wakeup_fd(fd) is unchanged: accept any file descriptors (int). On Windows, signal.set_wakeup_fd(fd) only accepts socket objects (socket.socket). (B) On UNIX, signal.set_wakeup_fd(fd) is unchanged: accept any file descriptors (int). On Windows, signal.set_wakeup_fd(fd) only accepts socket handles (int). (C) signal.set_wakeup_fd(fd) is unchanged but it is no more available on Windows (signal.set_wakeup_fd does not exist anymore, same change for PySignal_SetWakeupFd). Add a new signal.set_wakeup_socket(socket) function which only accepts socket objects (socket.socket), available on all platforms. The issue #22042 (make the file descriptor or socket automatically non-blocking) can be implemented with any of these options. The option (A) is really ugly: only accepting int on UNIX and only socket.socket on Windows doesn't look like a portable API. I don't like the option (B). Sockets are usually stored as objects (socket.socket) because of Windows, not as socket handle (int) So my favorite option is (C). On Windows, socket.fileno() returns a socket handle. Even if socket handles and file descriptors look the same (small integers), their namespace are completly separated. Operations on socket handles don't accept file descriptor. Operations on file descriptors don't accept socket handles. Socket objects are preferred for portability. For example, socket.send() works on all platforms. The option (C) also avoids the need of guessing the file type. On Windows, there is no function to check if a number is a file descriptor or a socket handle. _PyVerify_fd() tells you if a number if a file descriptor or not. But there is no public Windows function to check if a number is a socket handle. The option (C) also makes the implemantion simpler: the signal module can: - call socket.setblocking(False) to make the socket non-blocking, - get directly the socket handle/file descriptor from the socket object (using the private C structure), - call the socket error handler instead of copying the code. I'm not sure that getsockopt(sock_fd, SOL_SOCKET, SO_ERROR, ...) is reliable. I had bad experiences why I designed os.get_inheritable(fd) vs os.get_handle_inheritable(handle): calling os.get_inheritable() with a handle created file descriptors, which is something really strange. I'm no more sure about that, but I remember a very strange behaviour. Python now has os.get_inheritable(fd) for file descriptors and os.get_handle_inheritable(handle) for handles (it is only used for socket handles in factor) to not guess. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22018> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
