selectors' closing behaviors completely inconsistent across selector types

Bắt đầu với selectors.py và so sánh SelectSelector, PollSelector và EpollSelector, tập trung vào close(), select(), fileno() và hành vi của closed. Xem xét ngữ nghĩa wakeup giữa các thread và sau khi đóng được đề xuất, sau đó bổ sung coverage cho từng loại selector và xác minh rằng các selector đã đóng phát sinh OSError, còn các lệnh gọi select bị chặn trả về như đã chỉ định.

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