gh-81554: Add add_reader support to ProactorEventLoop

[minrk]

Runs select.select in a background thread when add_reader/writer are called. Thread is terminated when the event loop is destroyed.

Solves a major problem with the default event loop lacking these methods (see #81554 for use cases).

Imports SelectorThread implementation to asyncio._selector_thread from Tornado 6.5.2 and uses it in ProactorEventLoop, fixing a longstanding compatibility problem with the default Windows event loop. Feel free to review _selector_thread, but note that it currently has almost no modifications to the original file from tornado (only removing some type hints not supported by the standard library).

Since this is only run on demand, no thread will be spawned for existing code that works on ProactorEventLoop, only new code that previously only worked on SelectorEventLoop or tornado's AddThreadEventLoop will now work with the default event loop.

It is possible to do this without a thread (trio does it), but it seems this is the simplest, most maintainable solution, as indicated in the discussion in #81554.

• Issue: Configuration of windows event loop for libraries #81554

---

📚 Documentation preview 📚: https://cpython-previews--141834.org.readthedocs.build/

[StanFromIreland]

Should this not be in https://github.com/python/cpython/blob/main/Misc/sbom.spdx.json?

See the devguide.

[minrk]

This is not perfectly as-is, since it is adapted and an excerpt, like Lib/asyncio/events.py and a number of others. That doesn't seem to fit the SBOM requirements, in my understanding? I don't see any of the other similarly adapted files in sbom.spdx.json.

[minrk]

After addressing review, it has diverged more substantially. This comment structure seems to be how adapted/partial content is handled. Is there anything in the dev guide for that? I couldn't find it. The SBOM page doesn't seem to apply or mention this sort of case.

[vstinner]

Would it be possible to avoid daemon thread?

[minrk]

#86128 discusses why this is a daemon thread. I believe we need to call

with loop._select_cond:
            loop._closing_selector = True
            loop._select_cond.notify()
        try:
            loop._waker_w.send(b"a")
        except BlockingIOError:
            pass

prior to thread.join() for it to wake and exit properly. It looks like I can make it a non-daemon thread if I register the atexit hook with the private threading._register_atexit.

I believe this is only needed to handle process teardown for unclosed event loops. If we can strictly guarantee that EventLoop.close() is called before non-daemon threads are joined, then I don't think this is an issue. But I don't personally know a reliable way other than threading._register_atexit.

atexit.register only runs after threads are joined, not non-daemon threads (hence #86128), meaning that switching the thread to non-daemon will hang process exit until select returns, because no wake is called. A public hook that does exactly what threading._register_atexit does would be great. But since this is now in the stdlib, I could use that here, I suppose (#86128 remains a problem for non-stdlib code, of course).

[vstinner]

"The resolution of the monotonic clock on Windows is usually around 15.6 milliseconds."

Note unrelated to this PR: that's no longer true in Python 3.13:

On Windows, monotonic() now uses the QueryPerformanceCounter() clock for a resolution of 1 microsecond, instead of the GetTickCount64() clock which has a resolution of 15.6 milliseconds.

[vstinner]

Overall, the change looks good to me. I didn't test it. I just trust tests and the code that I read :-) I would prefer to have a second review from another core dev.

@kumaraditya303: Would you be interested to review this change?

[vstinner]

Is this sleep really needed? If yes, can it be replaced with a synchronization primitive instead of a sleep?

[minrk]

I would love help writing tests to verify that things don't happen in multithreaded code.

This was added to demonstrate an answer to the question in review that the select loop doesn't keep firing away if the main loop is slow to process one event, and was the best I could come up with to demonstrate that it really is waiting and only calls select once.

The sequence of events that we want to wait for is that the select thread is waiting in select_cond.wait() after select is called the first time. Maybe there's a way to instrument that.