The GDBDebugSession maintains a state isRunning and guards various actions depending on that value. However, a synchronous check of that value isn't guaranteed to accurately reflect GDB's state by the time it tries to process an MI command: some other part of the adapter code could have issued a continue command without GDB having yet emitted the event indicating that it has continued.
I'd suggest that we implement something like a tryIfNotRunning method along the following lines:
That would centralize the handling of the error that such and such a command can't be handled while the target is running. I bet we could clean up the types a bit, too, for ergonomics.
The
GDBDebugSession
maintains a stateisRunning
and guards various actions depending on that value. However, a synchronous check of that value isn't guaranteed to accurately reflect GDB's state by the time it tries to process an MI command: some other part of the adapter code could have issued acontinue
command without GDB having yet emitted the event indicating that it has continued.I'd suggest that we implement something like a
tryIfNotRunning
method along the following lines:That would centralize the handling of the error that such and such a command can't be handled while the target is running. I bet we could clean up the types a bit, too, for ergonomics.