The select module epoll.poll method takes a "timeout" parameter which is documented as having a default value of -1 [1]. If no timeout (or None) is passed to epoll.poll, then a value of -1 is passed to the epoll_wait system call. But if a timeout of -1 is passed to epoll.poll, then a value of -1000 is passed to epoll_wait. This is because the timeout is converted from seconds to milliseconds.

Before Python 3.5, if a negative timeout was passed to epoll.poll then -1 was passed to epoll_wait [2].

The Linux epoll_wait documentation doesn't specify the behaviour if timeout < -1. Linux itself behaves the same for all negative timeouts: never time out. But on Illumos, timeout < -1 currently times out immediately, and only timeout == -1 never times out [3].

Some code does pass -1 to select.epoll.poll expecting it to never time out. For example, selectors.EpollSelector [4].

I suggest restoring the pre-3.5 behaviour: epoll.poll should use -1 if the given timeout is negative.

I discovered this because ipython3 uses selectors.EpollSelector on Illumos,
and it was using 100% cpu while waiting for input because epoll_wait was returning immediately.

To demonstrate the issue you can run:

    strace python3.5 -c 'import select; select.epoll().poll(timeout=-1)' &

On Illumos this completes immediately, and the output contains the -1000 timeout:

    epoll_wait(3, [], 1023, -1000)          = 0

On Linux, it will block. If you then kill the python process with SIGTERM, strace should print the interrupted epoll_wait call, revealing the -1000 timeout:

    epoll_wait(3, 
    ...
    299a070, 1023, -100)        = -1 EINTR (Interrupted system call)

[1] https://github.com/python/cpython/blob/b9e40ed1bcce127893e40dd355087cda7187ac27/Modules/selectmodule.c#L1489
[2] https://github.com/python/cpython/commit/02e27d1301ea680dce9c3013010e3befedf9628a
[3] https://github.com/joyent/illumos-joyent/issues/136
[4] https://github.com/python/cpython/blob/8228a2b306844a213eddb4fb908c1925840ff67e/Lib/selectors.py#L428