I think this needs to be unified with wait_for_thread_shutdown. Threads created from Python may spawn threads in C and vice versa.

As currently written, I think you can get to wait_for_native_shutdown() and then have a thread spawn a threading.Thread() that's not waited on.

Yeah, I thought this might be an issue. Especially since there seems to be some inclination for a PyThreadState_GetDaemon function, unifying these seems like a good idea.

My main concern is breakage towards people who are manually using threading._shutdown for whatever reason. We'd have to remove that if we treat threading threads as native threads (or I guess we could have threading._shutdown call wait_for_native_shutdown?).

I think this problem is out of the scope of PEP 788. Pending calls or atexit handlers can also start threads, so we need to fix this in some other way. I think a loop that runs all these finalizer functions until there's nothing called anymore should work.

I disagree. Spawning threads from other threads is a very common operation. Spawning threads from atexit handlers is not.

Right, but we should fix it anyway. You can get some nifty fatal errors if you do something like this right now:

import atexit
import threading

@atexit.register
def start_thread():
    threading.Thread(target=print, args=("hello world",)).start()

My point is that we should implement that fix regardless of PEP 788, and then update the reference implementation once it lands. Is that ok?

One of the properties of PyGILState_Ensure() was that if you hade code that did something like:

Py_BEGIN_ALLOW_THREADS
...
PyGILState_Ensure();

Then the PyGILState_Ensure() code would reuse the same thread state; it wouldn't create a new one just because the thread state isn't active. The equivalent code with PyThreadState_Ensure() would create a new thread state.

This can come up when you release the GIL and make a possibly long running call into a C library function, which then calls back into Python.

• I didn't see this in the PEP. I think it's worth mentioning if it's not already there.
• Creating thread states unnecessarily can be expensive
• Creating a new thread state means that you have different thread local variables and other weird behavior.

Ok, we can reuse the gilstate pointer for this case. That has the additional benefit of being compatible with PyGILState_Ensure at the same time. Thanks for bringing this up.

(I'll update the PEP in a big "round 1 comments" PR sometime tomorrow or in the next few days. I want to give people a chance to look at the current draft first, so I can get a good idea of what needs to change.)

minor, but this decrements the count of non-daemon threads, right? It's not a count of daemon threads.

Oh yeah, oops.

Is it possible to interrupt it with CTRL+C? If not, maybe PyEvent_WaitTimed() should be called in a loop and call PyErr_CheckSignals() time to time?

You might rename 'entry' to 'ensured'.