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

See thedevguide.

This is not perfectly as-is, since it is adapted and an excerpt, likeLib/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.

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.

Would it be possible to avoid daemon thread?

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

withloop._select_cond:loop._closing_selector=Trueloop._select_cond.notify()try:loop._waker_w.send(b"a")exceptBlockingIOError:pass

prior tothread.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 privatethreading._register_atexit.

I believe this is only needed to handle process teardown for unclosed event loops. If we can strictly guarantee thatEventLoop.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 thanthreading._register_atexit.

atexit.register only runsafter threads are joined, not non-daemon threads (hence#86128), meaning that switching the thread to non-daemon will hang process exit untilselect returns, because no wake is called. A public hook that does exactly whatthreading._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).

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

Note unrelated to this PR: that'sno 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.

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

I would love help writing tests to verify that thingsdon'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.