selectors' closing behaviors completely inconsistent across selector types

从 selectors.py 开始，比较 SelectSelector、PollSelector 和 EpollSelector，重点关注 close()、select()、fileno() 以及 closed 的行为。审查提议的跨线程唤醒和关闭后的语义，然后为每种 selector 类型添加覆盖，并验证已关闭的 selector 会引发 OSError，且阻塞的 select 调用会按指定方式返回。

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).