selectors' closing behaviors completely inconsistent across selector types

Beginne mit selectors.py und vergleiche SelectSelector, PollSelector und EpollSelector, wobei du dich auf close(), select(), fileno() und das Verhalten von closed konzentrierst. Überprüfe das vorgeschlagene Cross-Thread-Wakeup- und Post-Close-Verhalten. Füge anschließend Abdeckung für jeden Selektortyp hinzu und verifiziere, dass geschlossene Selektoren OSError auslösen und blockierte select-Aufrufe wie angegeben zurückkehren.

Several behaviors in selectors differ across implementations in major ways.

1. What happens when a selector is selecting and is closed from a different thread?
2. What happens when a selector is closed and select is called thereafter?
3. What error (if any) is raised if a selector cannot be used after close.

While individual select implementations can exhibit selector-type-specific behaviors, selectors provides a high-level abstraction that should behave in a consistent fashion.

Examples of inconsistent behaviors (select-after-close):

Python 3.10.4 (main, Mar 28 2022, 17:39:22) [GCC 11.2.1 20220127 (Red Hat 11.2.1-9)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import selectors
>>> s = selectors.SelectSelector()
>>> s.close()
>>> s.select()
^CTraceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/arcivanov/.pyenv/versions/3.10.4/lib/python3.10/selectors.py", line 324, in select
    r, w, _ = self._select(self._readers, self._writers, [], timeout)
KeyboardInterrupt
>>> s = selectors.PollSelector()
>>> s.close()
>>> s.select()
^CTraceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/arcivanov/.pyenv/versions/3.10.4/lib/python3.10/selectors.py", line 416, in select
    fd_event_list = self._selector.poll(timeout)
KeyboardInterrupt
>>> s = selectors.EpollSelector()
>>> s.close()
>>> s.select()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/arcivanov/.pyenv/versions/3.10.4/lib/python3.10/selectors.py", line 469, in select
    fd_event_list = self._selector.poll(timeout, max_ev)
ValueError: I/O operation on closed epoll object

Proposal:

1. Closing a selector (from a different thread) while it is blocked in a select will always result in select returning immediately with no ready keys. This indicates EOF if timeout=None or is indistinguishable from timeout otherwise. See [4].
2. All selectors will have a fileno() regardless of implementation.
3. In all cases where selector is call-based (select/poll) a sentinel file (os.pipe) will be used as a fileno() and never returned in the ready list.
4. Selecting on a closed selector will result in an OSError irrespective of the underlying implementation.
5. Analogous tofile object, closed property returns True when selector is closed.

In cases when a selector implementation is not backed by a file-based object, this will result in 2 more file handles used per selector created (either a pipe or a socketpair).