Closed jacdavis closed 7 years ago
@jacdavis today a thread has an id and a name.
Could you please propose the name and description of the additional fields and a suggestion how a UI could make use of them.
You said 'optional string arguments on the thread event'. Do you really mean 'event' here?
Above is a screenshot of the necessary data in VS. I would suggest "RuntimeId" to allow a high level runtime to specify a virtual thread id or identifier (string would be more flexible than number here. Category:String to allow the engine to specify the type of thread. And "Name" string on the thread event. We would also likely need a second event to support the name changing dynamically.
Note that it isn't completely clear to myself and Gregg what the purpose of this exercise is. If we're just trying to enable debug adapters in VS, then edge case feature like this aren't necessary. However, if we are hoping to the core debug engines in VS to using this protocol, we'll need to fill in the missing features. We already know we'll likely need a non-protocol back channel for Intellitrace and the PerfDebugger/profiler.
his feature request will not be considered in the next 6-12 months roadmap and as such will be closed to keep the number of issues we have to maintain actionable. Thanks for understanding and happy coding!
In order to use the vscode protocol in vs, we'd need to have a second runtime specific identifier (matches the managed thread id in vs) as well as thread category (optional string) and optional name (Main Thread, GC Thread, none etc...) I think these could easily all be optional string arguments on the thread event. However, a thread name may change dynamically (for instance in native, a thread's name is changed by throwing a specific exception code).