I considered adding a unit test for _threading_atexit() that would attempt to register a mock object, and ensure it was called once after thread shutdown process is complete. However, upon trying to implement it, I think it might be a bit more trouble than it's worth for a fairly simple internal function.

That being said, I think it would be worthwhile to add a test along those lines if it were to be added to the public API for threading.

🤖 New build scheduled with the buildbot fleet by @aeros for commit 21a12e9 🤖

If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again.

(Note that AMD64 Windows7 SP1 PR and x86 Windows7 PR can be safely disregarded since Windows 7 isn't supported on 3.x)

I'm 99.99% certain the test_socket failure in FreeBSD Shared PR is unrelated to the PR, as it has been occurring intermittently in recent commits to master as well. Also, it's further reinforced by the fact that this PR doesn't affect the socket module.

1 re-run test:
    test_socket
Total duration: 33 min 55 sec
Tests result: FAILURE then FAILURE
sys:1: ResourceWarning: unclosed <socket.socket fd=5, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=132, laddr=('127.0.0.1', 51870)>
ResourceWarning: Enable tracemalloc to get the object allocation traceback
sys:1: ResourceWarning: unclosed <socket.socket fd=4, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=132, laddr=('127.0.0.1', 52586)>
ResourceWarning: Enable tracemalloc to get the object allocation traceback
sys:1: ResourceWarning: unclosed <socket.socket fd=3, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=132, laddr=('127.0.0.1', 49295)>
ResourceWarning: Enable tracemalloc to get the object allocation traceback
*** Error code 2

I opened a separate issue to address the (unrelated) buildbot refleaks from test_asyncio at https://bugs.python.org/issue40061.

Thanks for doing this.

No problem, thanks for the review. :-)

I think _register_atexit deserves at least some basic unit test(s). It should be fairly easy by spawning e.g. a subprocess and checking its output.

Yeah, after having some additional time to think about it, I think we'd be better off with a couple of basic unit tests for it, even if it's internal. I'll work on those next.

Going to restart the CI (via close and re-open) since it failed in the "Install Dependencies" stage.

@pitrou I believe that I've addressed the review comments. Let me know if the unit tests I added are sufficient.

(closing and reopening to trigger CI)

Also, would it be worth adding a "What's New" entry to mention that the executors no longer rely on daemon threads?

That's a good idea.

Oh, and yes, the unit tests look sufficient for an internal function :-)

@pitrou

(closing and reopening to trigger CI)

By the way, with GitHub actions for some reason, it leaves the previous CI failures and duplicates the tests when you close and re-open the PR. So some of the failures showing are from the first time (before I closed and re-opened it), that's why there's 3 of each GitHub actions test.

I'm not certain why they're failing in the early stages though. If it happens again, I'll start a thread on python-dev.

That's a good idea.

Great! I'll work on the "What's New" entry next; it shouldn't take long. :-)

(It should also clear the old CI tests since it's a different commit)

@gvanrossum this PR needs to be reverted, but I no longer have my commit bit

This PR needs to be reverted, but I no longer have my commit bit

Please open a new issue with reasoning.

In general we do not want daemon threads anywhere anymore. Their existence has turned out to be a misfeature as they mean you cannot safely finalize a Python runtime when such threads are present.

I am also curious why @aeros stated that this needs reverting. It looks like a backwards incompatible change (which is why I ended up reading this ticket), but it looks like affected projects can easily cope.

Did run into this because I manipulate interpreter shutdown for a test suite, which at times got stuck due to some non-daemon thread "helpfully" started in some library package. That code is not used in production but for diagnostics, as the failure was intermittent and difficult to reproduce.

In general we do not want daemon threads anywhere anymore.

I think nobody "wants" units of execution that are just killed without notice in whatever state they are. I'd just like to advise against dropping them without a replacement.

The use case I see is dealing with threads getting stuck in some native code. This came up in my career a few times and was always a giant PITA to solve (or, actually, work around). What I'd like is a way to detach a thread in a way that it may not come back from extension code and just silently stops. I am not sure if and how that could be implemented, though.

Sorry for the noise, got longer than anticipated.

@Bluehorn Useful explanation, thank you. I think @gpshead 's statement "Please open a new issue with reasoning" still holds, though.

I am also curious why @aeros stated that this needs reverting.

The leading theory is that he lost control over his account. That account's permissions have been dropped.