> If the debug adapter is started when the debug session is started, it will go away with the session (as is should, because any new sessions will start a new copy). If it is started outside of debugger control (running as a resident process available via socket,
for example), it will still be there when we come back, no?
Both statements are true. But what I meant was regarding the support for conserving debugging sessions across reloads. In this case some kind of persistence would need to be done in the backend to keep those alive as the frontend kills its whole runtime+connections
and reboots. Not a big deal but since you mentioned the use-case I was curious if you'd take that into account or not. But as you said: as of today reloading kills sessions, so it could be out of scope for now.
From: Thomas Mäder <tmader@xxxxxxxxxx>
Sent: Friday, October 8, 2021 11:02 AM
To: Paul Marechal <paul.marechal@xxxxxxxxxxxx>; theia-dev@xxxxxxxxxxx <theia-dev@xxxxxxxxxxx>
Subject: Re[2]: [theia-dev] Debugger architecture musings
------ Original Message ------
From: "Paul Marechal" <paul.marechal@xxxxxxxxxxxx>
To: "Thomas Mäder" <tmader@xxxxxxxxxx>; "theia-dev@xxxxxxxxxxx" <theia-dev@xxxxxxxxxxx>
Sent: 08/10/2021 16:08:34
Subject: Re: [theia-dev] Debugger architecture musings
You got me at "simplify".
Regarding 1) if we move the DebugService to the frontend then debug sessions will have even more reasons to be destroyed. If we want persistence of those, we need to at least persist the debug adapter processes
in the backend.
If the debug adapter is started when the debug session is started, it will go away with the session (as is should, because any new sessions will start a new copy). If it is started outside of debugger control (running as a resident process available via socket,
for example), it will still be there when we come back, no?
/Thomas