Support for multi-target / multi-session / fork debugging

[hoehrmann]

Over at https://github.com/pullhub/vscode-perl-debug/tree/fork I am playing with multi-session/multi-target support, mainly to support fork (as a diff, https://github.com/pullhub/vscode-perl-debug/commit/7676bf375c794470f77f521c1feb5d02d05cfcd1 should do for the moment). Suppose the Perl script to be debugged is on a remote server:

1. The user launches a remote debugging configuration in vscode
2. The debug adapter listens on port $localPort for the Perl debugger
3. The user uses ssh to forward localhost:$localPort to remote:$remotePort
4. The user launches PERLDB_OPTS='RemotePort=localhost:$remotePort' perl -d script.pl on the remote server
5. The Perl debugger connects to the debug adapter (via the ssh forwarded port)
6. The script runs, and then forks a child process
7. The debug adapter receives a new incoming connection from the Perl debugger attached to the child process
8. Now what?

At the moment the extension would simply refuse the new connection...

It seems vscode needs a new debug adapter instance for each new process / debug session. That pretty much leaves only one option, one perlDebug.ts instance has to be a relay for other instances (since we cannot simply hand over sockets from one process to the other).

So my changes linked above have a simple proxy server that makes an accepted connection indirectly attachable for a new perlDebug.ts process. Basically:

1. perlDebug#1 listens on ip:1
2. debugger#1 connects on ip:1
3. things work as they always have
4. debugger#2 connects on ip:1
5. perlDebug#1 listens on ip:2
6. extension creates perlDebug#2
7. perlDebug#2 attaches to ip:2
8. perlDebug#2 talks through perlDebug#1 to debugger#2

There probably is no better way to do this while maintaining proper process isolation. My code works, but I am not yet happy with where things live and lifecycle management is a bit broken.

I am currently trying to unify LaunchRequestArguments with LaunchOptions to simplify how perlDebug.ts and adapter.ts do launches. I kinda would like to lift »perlDebug#1 listens on ip:2« out of remoteSession.ts but I am not clear on where things should go.

[hoehrmann]

One use case to consider:

It seems to me that remote debugging sessions should, perhaps at user option, have a longer lifetime than the first script that might connect to it. Suppose you have a bash script that configures an environment for several Perl scripts and you want to debug one of the scripts. It should be possible to start a remote debugging session in vscode and then run something like the following:

% export PERLDB_OPTS='RemotePort=localhost:5000'
% export PERL5OPT=-d
% bash -x script-that-calls-several-perl-scripts.sh

If the remote debugging session endures until the user decides to end it, this should work fine. If however we end the debugging session when the first script terminates, the user has only bad options, they would, for instance, have to fiddle with the bash script to make sure the debugger is launched only once.

The same problem probably exists when the first Perl script forks a child and then terminates itself, like a daemon might do to run in the background, we would not get to the point where the user could debug the forked child since the launch process has gone already.

[hoehrmann]

Pondering a launch.json option to give users control over this:

sessions: 'single' | 'watch' | 'break'

The current behaviour could be single.

In watch mode multiple sessions are accepted, probably with an extended lifetime of the debug session (users might have to manually terminate it, or there might be a configurable timeout?).

The break mode is like watch except that new sessions, child processes, are stopped on entry.

[hoehrmann]

Now https://github.com/raix/vscode-perl-debug/pull/77

[hoehrmann]

Fixed by merging my PR in https://github.com/raix/vscode-perl-debug/commit/2cda8962aef231fdbb70013e54559563afbcb9db