Description
Splitting this from the discussion in flutter/flutter#170804
Currently many editors don't allow users to set breakpoints per-thread/isolate (I'm not even sure how this would work, since we need to pause the isolate at startup to send them, but the user wouldn't be able to assign breakpoints to them before they exist), so the current VM Service APIs of setting breakpoints per-isolate result in a lot of complexity. Clients need to watch for new isolates and send breakpoints to them, and when breakpoints are modified, they need to make the same changes for all isolates.
It would be much more natural for a client/debug adapter to just set breakpoints once, and have them automatically applied to all current and future isolates.
The same is true for exceptionPauseMode and ideally the libraryDebuggable flags, although that one might be more tricky since it's per-library and new isolates may load more libraries (although I'll note that VS Code only ever sets these in groups of "my code", "sdk code" and "other code - code not in my workspace" so if the VM was aware of those groups, that could work).
could be as simple as adding an optional parameter to the RPCs to specify whether or not the operation should apply to the isolate's isolate group.
You mention isolate groups here, but actually I'd prefer all isolates from all groups, because groups aren't visible in the editor either, so there's still going to be complexity/redundancy doing it for all groups. I don't know how much more complicated that is though.
I think this also raises some questions about the breakpoint events... Probably we'd still get an event per-isolate saying a breakpoint was added, but I think ideally the end goal would be that the fact that breakpoints are per-isolate is abstracted from the editor/debug adapter, and it can just assuming a simple model of a single set of breakpoints globally.