-
-
Notifications
You must be signed in to change notification settings - Fork 123
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Debugging Subinterpreters #273
Comments
Hi @FlorianKroiss I haven't really done much with subinterpreters so far, so, I don't really know what'd be the repercussions. Now, related to the reader thread being alive, what the comment says is that there should be kind of a ping-pong, where the writer thread is closed, then the clients reader thread becomes closed which in turn should close its writer which should then automatically stop the reader thread. I guess that in this case things happen too fast for that ping-pong to happen (the subinterpreter probably gets shutdown before all of that happens). In that case, I think you could call:
|
Hi @fabioz, thanks for the quick reply. Unfortunately, your suggestion did not solve the problem at hand. From what I understand, It seems to me that the ping-pong that you described is not happening, i.e., the ReaderThread is still running, even after a longer wait time. Trying to explicitly join on the ReaderThread hangs indefinitely, so I don't think it's a timing problem:
I'm using PyDev from within Eclipse to start the Debug Server. When I explicitly stop the running interpreter from Eclipse, using 'Terminate (Ctrl+F2)', the ReaderThread properly closes, but when I just resume the Python program after a breakpoint, the ReaderThread keeps running. I would be grateful if you had any more ideas. |
Humm, if you call I think you can use the workaround you're suggesting for now (the only downside is that you could still have some upcoming message to do something which wouldn't be received in this case... usually not a problem, the main issue is that some output message would not be reaching the client and you'd loose that message). |
We are using jep and Subinterpreters to invoke Python code from within a Java process.
Ideally we would like to debug the execution of such code with PyDev's remote debugger.
Using the following code example we are able to use a remote debugger.
However, after calling
pydevd.stoptrace()
it seems that there still is a daemon thread alive which then causes an error when the Subinterpreter is closed, as it requires that no other thread (daemon or not) is still running:From the stacktrace we can see that the
ReaderThread
is still running. From the comment ondo_kill_pydev_thread
it seems that this is intentional.I guess that keeping the ReaderThread alive is reasonable when debugging a regular Interpreter, but not when running within a Subinterpreter. Our current workaround is to manually shutdown the ReaderThread by essentially running the code that is commented out in it's
ReaderThread.do_kill_pydev_thread
:Would it be possible to add an argument to the
stoptrace
function which makes sure that all pydevd threads are actually killed?Are you aware of any quirks that one might encounter when debugging within a Subinterpreter?
I guess that this issue might also become more relevant with PEP-734
The text was updated successfully, but these errors were encountered: