I think that signal.set_wakeup_fd(fd) must set the file descriptor to the non-blocking mode, instead of requiring the file descriptor mode to be non-blocking.

Atttached patch implements this idea.

See also the issue bpo-22018 which proposes to support sockets in signal.set_wakeup_fd(fd) on Windows.

We have to decide if signal.set_wakeup_fd() is supposed to support files or not on Windows. Non-blocking mode does not exist for files on Windows, only for sockets.

I didn't test my patch on Windows yet.

Note: the new _Py_set_blocking() function tries to use ioctl() instead of fnctl() when available to only use one syscall instead of two. I used the same optimization in _Py_set_inheritable().

I think it would be much better to expose a generic function to make a fd non-blocking, rather than bake it inside signal.set_wakeup_fd().

Also, given set_wakeup_fd() is rather specialized and uncommon, I don't see much point in making it more convenient.

"Also, given set_wakeup_fd() is rather specialized and uncommon, I don't see much point in making it more convenient."

The problem is that passing a blocking file descriptor can block the whole Python process. The hang does not occur immediatly, but only when the pipe is full for example, which may only occur in some corner cases (ex: heavy system load, slow network, etc.).

The minimum would be to raise an error if the file descriptor is in blocking mode.

New changeset 9dc66b3a1d0d by Victor Stinner in branch 'default':
Issue bpo-22042: Avoid dangerous C cast in socket.setblocking()
http://hg.python.org/cpython/rev/9dc66b3a1d0d

As suggested by Antoine, I created the issue bpo-22054 to add os.get_blocking() and os.set_blocking() functions.

Here is the simplified patch for signal.set_wakeup_fd(fd). It now depends on the patch of the issue bpo-22054.

signal_check_nonblocking.patch: signal.set_wakeup_fd() now raises a ValueError if the file descriptor is in blocking mode.

The patch depends on the patch of the issue bpo-22054.

I didn't test the patch on Windows, but all calls to signal.set_wakeup_fd() must fail with ValueError since it's not possible to set a file in non-blocking mode. See the issue bpo-22018 which proposes to support sockets for signal.set_wakeup_fd().

On Windows, it looks like it's not possible to test if a socket handle (int, not a socket object) is blocking or not. The WSAIsBlocking() function was removed, it's only possible to set the flag using ioctlsocket().

I commited my patch to support sockets in signal.set_wakeup_fd() on Windows.

I updated my patch. It doesn't change signal.set_wakeup_fd() on Windows anymore. It only raises an exception on POSIX if the file descriptor is blocking.

On Windows, it's not possible to make a file non-blocking and so the signal handler may block on writing in the file. Antoine Pitrou doesn't want to change the behaviour, he prefers to still support files even if there is the possible hang.

On Windows, it's not possible to check if a socket handle is blocking or not. So set_wakeup_fd() doesn't check if the socket is blocking or not on Windows.

At least, the check can be implemented on POSIX.

--

An alternative is to make the file descriptor non-blocking in set_wakeup_fd(). In this case, I suggest to drop support of files on Windows because files cannot be set in non-blocking mode.

New changeset d984dfe8c34e by Victor Stinner in branch 'default':
Issue bpo-22042: signal.set_wakeup_fd(fd) now raises an exception if the file
http://hg.python.org/cpython/rev/d984dfe8c34e

New changeset f5f5553f219e by Victor Stinner in branch 'default':
Issue bpo-22042: Fix test_signal on Windows
http://hg.python.org/cpython/rev/f5f5553f219e