Paging support for threads

[polinasok]

Similarly to paging support for stackTrace, it would be quite useful if DAP provided paging support for threads.

We came across this with Go goroutines - lightweight virtual threads, where loading all of them at once is quite costly and can even freeze the system (e.g. golang/vscode-go#129). A concurrent Go application can have hundreds of thousands of goroutines, maybe even millions. It is questionable how much interactive debugging happens at that scale, but paging is helpful even if there are only hundreds of threads, a possibility for other languages as well. This would make it possible for editors to limit the amount of threads to display to something manageable and to load more on demand, perhaps with a feature to look up a specific thread by some kind of id/label or condition.

[gregg-miskelly]

I feel like a better option is not try to treat massive parallelism as DAP threads - we would really need a new concepts for .NET Task chains/JavaScript promise chains/goroutines/GPU threads/etc where the backend has done the work for grouping (example).

[connor4312]

Regarding what Gregg mentioned, that feels like something that would could be implemented in a custom webview. Different languages start to have varying capability and display needs when you get to the point of trying to visualize concurrency, and having a webview could let you tailor that to your needs...

For go specifically you could show the existing pprof web UI (perhaps with tweaks to reuse the user's editor colors?) in a webview which would be a great experience for me as a Go user.

The question of usable realtime debugging for green thread-style runtimes is harder for me to think of. For every long running goroutine you can have many more goroutines that run and exit in milliseconds or microseconds (e.g. an http request). You would probably not want to show these in the UI unless the runtime is paused, as that flickering would not be a good user experience and could also degrade UI performance doing lots of mutations.

[gregg-miskelly]

RE: Custom web view
Yup, that has been our plan for bringing .NET Task visualization to VS Code (no immediate plans, but something we have thought about). But this issue does make me question that a bit - it is a common problem across all major programming languages today. So maybe it would be possible to come up with protocol to allow a unified UI.

Note that short tasks aren't a problem - this isn't a UI that you have up all the time. You bring it up when you are experiencing a hang and you are trying to understand why. You close it once you understand.

[polinasok]

I am all for a better way to represent threads vs goroutines/tasks/etc. Go can have threads that are not executing goroutines, and we are not displaying those at all right now because there isn't a clean way to differentiate.

Specifically in Go the threads list is not refreshed when the program is running. Whatever the threads were at the last stop, their status will just change to "Running", but new ones won't flicker back and forth until you stop again.

Even with the flattened threads view, if tasks/goroutines/etc are labeled in a way to differentiate between short and long running ones, you could also have a filter to minimize what the UI shows. Or maybe you could filter by state - paused on some reason (e.g. all that hit breakpoints).

[hyangah]

Would be nice if there is a better way to represent these green-thread like things as they are getting more popular in modern languages. Sometimes I need to inspect both underlying threads and goroutines, and the unified vscode UI and the current Go DAP does not offer the path.

Each language DAP implementation can come up with a separate webview that speaks a custom message, but there are many questions to answer - should we also implement other related methods for stop/pause, inspecting each call stacks on them, associating between the low-level thread and goroutine outside the standard DAP protocol?

Editors like VSCode offer default unified UI elements based on the standard DAP. IMO that's one of the biggest values DAP brings in. If
the default UI doesn't understand the green threads, while most users who will need the UI are supposed to interact with goroutines/green threads rather than the low level threads, that is not an ideal situation.

[weinand]

The problem with "custom web views" (or any other custom UI) is that they live outside of DAP which prevents them from being easily reused across different clients ("Custom web views" have a slight advantage over other custom UI because clients might provide "custom web view" support more easily).

So I agree with @gregg-miskelly and @hyangah: if "green-thread like things" are a common problem across major programming languages today then we should try to come up with some protocol...

[puremourning]

So I agree with @gregg-miskelly and @hyangah: if "green-thread like things" are a common problem across major programming languages today then we should try to come up with some protocol...

Strongly agree. There's no way that at client could display a 'custom web view' in a TUI.