STINNER Victor added the comment:
> 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.
----------
Added file: http://bugs.python.org/file36011/signal_socket-2.patch
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue22018>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
