Continue request shouldn't fall back on continuing all threads, when a single thread can't be continued

[roblourens]

"Continue" currently says that if it can't continue just one thread, it should continue all threads.

The protocol shouldn't specify a fallback on different behavior - instead the continue request should fail, while a continue request without a threadID should mean "continue all threads".

@weinand:

I agree that the fallback semantics is a bad idea. Please file DAP protocol bug for this.

But please note that it might be impossible to fix this in the current version of the DAP in a non-breaking way.

cc
@mostafaeweda
@ebluestein

[ebluestein]

Sounds totally reasonable to me. Another option would be a supportsContinueSingleThread capability, and the client would query this flag to determine if this debugger has the current fallback behavior or not

[gregg-miskelly]

Suggestion: change the doc to "if it can't continue just one thread, a debug adapter can continue all threads and issue a continued event indicating a threads have been continued". This is what the C# debug adapter does.

[ebluestein]

I think the issue here is that the UI has no way of knowing if the debugger is going to go ahead and continue all threads, and therefore has no way of opting out if that's not the right behavior.

For example, if I could right click a paused thread in a Threads view, and choose "continue this thread" in some UI - I think the correct behavior would be to either continue that one thread, or give the user an error. Resuming all threads is not what I asked for

[ebluestein]

(I consider this to be pretty low priority though)

[gregg-miskelly]

Got it.

I think the docs probably still should be adjusted in a way similar to what I suggested as I don't think we want to change VS Code (or other debugger UIs) to have them stop passing thread ids to the primary execution commands. But it might be useful to support some sort of new capability to opt-out of the explicitly single-threaded execution commands.