Thread suspend policy for multi-threaded applications

[jonasehrlich]

I hope this is the right place for this question / discussion, please redirect me if there's a more appropriate place.
One feature I am really missing after switching from PyCharm, is the specification of a suspend policy for breakpoints (https://www.jetbrains.com/help/pycharm/using-breakpoints.html#properties).

Consider the following scenario:

• Debugging a client application, that cannot connect to its server directly
• Connection to the server is not directly possible, so a (daemon) thread is started to do a SSH local port-forwarding to tunnel communication between the client and the server

This works fine, while the application is running, but when hitting a breakpoint all threads are suspended and any requests fired from the debug console time out, because the forwarder thread is obviously suspended as well.

When clicking "Continue" any of the forwarder threads, the MainThread will continue to run as well, which is obviously not the desired behavior.

Is there something I am missing here, or is this a limitation of debugpy / the DAP?

[karthiknadig]

There is a setting you can add to launch json, steppingResumesAllThreads. This is by default true, but you can set it to false and then step and that allows only the current thread to continue. The limitation here is that it only works with stepping.

        {
            "name": "Python: Current File",
            "type": "python",
            "request": "launch",
            "program": "${file}",
            "console": "integratedTerminal",
            "steppingResumesAllThreads": false
        }

/cc @int19h, @fabioz

[fabioz]

As a note, the steppingResumesAllThreads enables making the step only in a single thread without resuming others, but it won't change the behavior that upon hitting a breakpoint all threads are suspended as the behavior is always pausing all threads upon a breakpoint hit...

For this case there are 2 options:

1. Set an environment variable such as PYDEVD_UNBLOCK_THREADS_TIMEOUT=0 (you may also set a timeout if you wish as 0 will make it resume all threads when the evaluation begins and not only after a given timeout). This will make other threads (all except the one where the evaluation was requested) run during the evaluation (this was done specifically for the use-case you're working with...).

2. If you need a thread to always run it is possible to ignore that thread in the debug session. To do that you can set the pydev_do_not_trace in the thread itself (you may also want to set is_pydev_daemon_thread to hide that thread as it won't be really possible to interact with it):

i.e.:

import threading
thread = threading.Thread(...)
thread.pydev_do_not_trace = True
thread.is_pydev_daemon_thread = True

If for some reason that's not enough for your use case, feel free to create an issue in https://github.com/microsoft/debugpy/issues.

[jonasehrlich]

Thank you @fabioz! The environment variable is actually the perfect solution for my use-case

[akr-amd]

@fabioz do I need to use both steppingResumesAllThreads=false in launch.json and env var PYDEVD_UNBLOCK_THREADS_TIMEOUT=0 for this to work? Given that its been 3 years, are these workarounds expected to work?

Never mind, user error. For some reason, I thought this was meant for the Microsoft Python Debugger for VS Code. I can confirm this works with the "Python Debugger (PyDev)" extension.