<div dir="ltr">Yes, I was expecting the nesting on the raw JSON. Volkan explained enough to understand the issue of nesting at the raw JSON, Thanks.<div><br></div><div>Regarding the naming, suppose we create a StructuredTaskScope with default constructor(without a custom thread factory), can we set a custom name to each subtask? If we can set a name for subtasks, it will be easy to trace the threads from the thread dump.</div><div><br></div><div>Regards,</div><div>Muneer</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 28, 2024 at 6:01 PM Alan Bateman <<a href="mailto:alan.bateman@oracle.com">alan.bateman@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 28/11/2024 11:46, Abdul Muneer K wrote:<br>
> I attached the test program and corresponding thread dump.<br>
> In this json tree structure, if tids 29 and 30 come under its owner <br>
> tid 20 in a tree structure, we can understand thread hierarchy easily <br>
> from the thread dump json file.<br>
> Similarly 31 and 32 under 29, 33 and 34 under 32, 26 and 28 under 23 <br>
> respectively.<br>
> Now all pairs of threads are coming under a single node <br>
> "threadContainers", it's not easy to understand the tree <br>
> hierarchy from that. It's possible to track the hierarchy based on the <br>
> owner/parent fields, but it's hard to follow if the hierarchy is long.<br>
><br>
> Also another comment, now all the virtual thread's name is coming as <br>
> an empty string in the thread dump. If the fork API can accept a name <br>
> also as an argument and pass that name as the thread name interanlly, <br>
> we can track the threads or tasks based on its name in the thread dump.<br>
><br>
<br>
There's a tree of "thread groupings". These are flattened into a JSON <br>
array. Each element in the array identifies the thread grouping, its <br>
owner if owned, its parent, and a "threads" array with the threads in <br>
the grouping. That's enough to reconstruct the tree and visualize it in <br>
a tool. This give you the thread parent-child relationship too. So is <br>
the issue, as Volkan has suggested, that you are expecting the nesting <br>
when looking at the raw JSON?<br>
<br>
The ThreadFactory that you can specify can name the threads. Subtasks <br>
can of course change the current thread name too.<br>
<br>
-Alan<br>
</blockquote></div>