When I use embedded Python to import and use threading module,The program will hang,I tested it in versions 3.6.5 and 3.9.1.

Please add more information about what you're doing.  Your report does not contain enough information to try to reproduce the problem.

This is supposed to work just fine, and does work for me.

I use cpython to running .py file,the file created a new thread,but the exe can't continue to run

Sorry, but as Ronald says there's not nearly enough information here. Some questions:

- What do you mean by "embedded Python"?
- What is "the exe" that you refer to in your second mesasge? Is that python.exe? Is that an executable you compiled from your Python code somehow? If so, how?
- What operating system are you using?
- What exact version of Python are you using, and where did you get it from? (Conda? python.org install? OS package manager? Pre-installed?)
- What other dependencies are you using? Any 3rd party packages?
- What's the exact Python code that you're running? (Please attach all the Python code, preferably after first reducing to a minimal example that exhibits the issue.)
- What are the precise steps you used to invoke the Python code? (Are you running as a script from a command-line prompt? Interactively in IDLE / PyCharm / VS Code / some other IDE?)
- What exactly happened?
- What did you expect to happen, and why?
- What steps have you taken to eliminate the possibility that this is a bug in your own code rather than in Python?

These notes may help: https://www.chiark.greenend.org.uk/~sgtatham/bugs.html

Sorry, I didn't make the question clear yesterday.
My operating system is Windows and the compiler used is VS2019. My project address: https://github.com/twoone-3/BDSpyrunner
When I use Python.dll to import Python files, the program is stuck. After checking, I found that as long as I use multi-threading, the program will be stuck. Of course, this Python file can be directly run by Python.exe, but from  My program cannot run normally when calling Python.dll

The file:
import threading
import time
 
def worker():
     print "worker"
     time.sleep( 1 )
     return
 
for i in xrange ( 5 ):
     t = threading.Thread(target = worker)
     t.start()

Have you been studying this problem?

[twoone3]

> Have you been studying this problem?

Not personally, no. Sorry, but I'm afraid this really isn't an actionable bug report as it stands: we still don't have an effective way to reproduce, and it's far from clear that this is actually a bug in CPython as opposed to a bug somewhere in the BDSpyrunner code.

If you're able to produce (and attach to this issue) a minimal self-contained C++ file that exhibits the issue, that could help increase the chances that we can confirm the existence of a CPython bug. Even better, if you're able to diagnose the issue yourself to the point where there's a clear CPython bug to report, that's much more likely to lead to a fix. (And those two actions - producing a minimal example, and diagnosis, should be largely compatible.)

After my test, when the exe calls the dll, the dll calls Python. If the Python code involves multiple threads, the process will be stuck.

Run Project1\x64\Release\Project2.exe

@twoone3: Shouldn't you be calling PyGILState_Ensure() before calling into Python from the C++ code?

In any case, I'm removing myself from the nosy list on this issue, because I don't have access to Windows to try to reproduce.

After adding GIL, the problem still exists. If you think this problem is incomprehensible, it may be because I used Google Translation ..

Sorry, I can't help. My employer has strict rules about reviewing GPL code like that in your linked repository.

I'd suggest checking your thread management in native code. Each new thread created in Python will create a new native thread, and they're all trying to acquire the GIL, so make sure you release it. I have no idea how you are waiting for the threads to complete their work, but you'll need to release the GIL while waiting (and maybe periodically reacquire it to check).

In general, I find it's best to treat embedded CPython as running as a separate process, even if it's just in separate threads. If you try and mix arbitrary Python code into your own application, things like this happen all the time. Whereas if you are doing inter-thread communication as if there are no shared objects, you'll often be fine.

That's a pity. I'm going to send the Python source code to my project to compile it, and see if it can solve the problem. Of course, I can also try compiling it into a static library