If a call to select.select() was interrupted by a signal and the select syscall set an errno of EINTR, then under PEP 475 the select call should be re-executed.

If, however, there is a signal handler which takes enough time that the select's timeout expires, select() is not retried, and the rlist is returned as-is (with fds in it which are not ready for reading).

Under this condition, either select() should be re-run with a timeout of 0, or the fd lists should be emptied before returning.

Example code which reproduces the problem attached.

I believe the offending line in the source is this break statement:
https://github.com/python/cpython/blob/master/Modules/selectmodule.c#L339

> Under this condition, either select() should be re-run with a timeout of 0, or the fd lists should be emptied before returning.

What is the current behavior?

Are you trying to fix a bug?

The current behavior is:

> select() is not retried, and the rlist is returned as-is (with fds in it which are not ready for reading)

Yes, this is a bug. It results in select() indicating that fd are ready for reading when they, in fact, are not.

Ah! I missed attached select_eintr.py script. Ok, I reproduced the bug and I agree that it must be fixed.

New changeset 7f52415a6d4841d77d3b7853e83b25a22e0048dc by Victor Stinner (Oran Avraham) in branch 'master':
bpo-35310: Clear select() lists before returning upon EINTR (GH-10877)
https://github.com/python/cpython/commit/7f52415a6d4841d77d3b7853e83b25a22e0048dc

Python 2.7 is not affected: select() isn't retried if it fails with EINTR.

New changeset b2e0649dd9a36d54478d0edb623a18d7379e6f19 by Miss Islington (bot) in branch '3.6':
bpo-35310: Clear select() lists before returning upon EINTR (GH-10877)
https://github.com/python/cpython/commit/b2e0649dd9a36d54478d0edb623a18d7379e6f19

New changeset 34510781901b75c9aeca79db41ce0fa92c67878f by Miss Islington (bot) in branch '3.7':
bpo-35310: Clear select() lists before returning upon EINTR (GH-10877)
https://github.com/python/cpython/commit/34510781901b75c9aeca79db41ce0fa92c67878f

Ok, the bug should now be fixed in 3.6, 3.7 and master branches.

Thanks Brian Maissy for the bug report and thanks Oran Avraham for the fix!

I hope that we will understand why I didn't want to add a new functional test ;-)