Ending debug session does not terminate PTVSD process running in a terminal

[DonJayamanne]

Currently termination of the PTVSD process is a responsibility of the VS Code debug adapter.
This works in scenarios where we're using the debug console (no-terminals involved).

However when debugging a Python program in an external terminal or the VS Code terminal, then stopping the debugger doesn't kill the PTVSD process. Though the program ends, the PTVSD process is still running, hence the terminal doesn't return to the prompt.

Solutions:

1. Kill PTVSD using the process id.
   Unfortunately VS Code doesn't return the process id of the process (when we send a request to launch the program in a terminal).
2. PTVSD could kill itself after it sends the response to the disconnect request.
   This would work well with VS and VS Code.
3. Implement a new protocol that would send the process id back to VS Code.
   Then VS Code could kill the process using this process id.
   This feels like a hack, when 2 would be better.

[DonJayamanne]

Looks the behavior of PTVSD has changed. Previously the program would pause and the process would not die. Now nothing happens.
Consider the following sample:

import time
for i in range(100)
    time.sleep(5)
    print(i)

• Previously stopping the debugger after 5 seconds (5 items printed), no output would be generated. and the process seems to just lie dormant.
• Now, the loop just continues, its like the stop command does nothing anymore.

[DonJayamanne]

Should we add a custom request, that would return the PID.
Yes this isn't ideal however it seems the current solution is to kill the process and VS Code doesn't have this.

Though I still believe the PTVSD should kill itself when it receives the disconnect request.
Besides it knows whether it was launched or attached, hence can decide for itself whether to die or just disconnect.

[zooba]

Make sure you’re testing with code that includes Python function calls. Without breakpoints or function calls the debugger may go into a mode that is harder to interrupt, which may also impact this situation.

[DonJayamanne]

Can be fixed with processid returned in process event #93