Fwd: Structured Concurrency - Stacktrace in tree hierarchical structure

[Alan Bateman]

On 28/11/2024 11:46, Abdul Muneer K wrote:
> I attached the test program and corresponding thread dump.
> In this json tree structure, if tids 29 and 30 come under its owner 
> tid 20 in a tree structure, we can understand thread hierarchy easily 
> from the thread dump json file.
> Similarly 31 and 32 under 29, 33 and 34 under 32, 26 and 28 under 23 
> respectively.
> Now all pairs of threads are coming under a single node 
> "threadContainers", it's not easy to understand the tree 
> hierarchy from that. It's possible to track the hierarchy based on the 
> owner/parent fields, but it's hard to follow if the hierarchy is long.
>
> Also another comment, now all the virtual thread's name is coming as 
> an empty string in the thread dump. If the fork API can accept a name 
> also as an argument and pass that name as the thread name interanlly, 
> we can track the threads or tasks based on its name in the thread dump.
>

There's a tree of "thread groupings". These are flattened into a JSON 
array. Each element in the array identifies the thread grouping, its 
owner if owned, its parent, and a "threads" array with the threads in 
the grouping. That's enough to reconstruct the tree and visualize it in 
a tool. This give you the thread parent-child relationship too. So is 
the issue, as Volkan has suggested, that you are expecting the nesting 
when looking at the raw JSON?

The ThreadFactory that you can specify can name the threads. Subtasks 
can of course change the current thread name too.

-Alan