<br><font size=2 face="sans-serif">On Nov 30th, 2009 &lt;ashley@pittman.co.uk&gt; wrote:</font>
<br>
<br><font size=2 face="Courier New">&gt; I've been giving some thought to how to padb can handle threaded<br>
&gt; applications better as the current scheme isn't ideal.</font>
<br><font size=2 face="Courier New">&gt; </font>
<br><font size=2 face="Courier New">&gt; </font>
<br><font size=2 face="Courier New">&gt; First would be to report extra threads in the same tree as the primary<br>
&gt; thread, some magic would have to be applied to cover the fact that the<br>
&gt; first thread in a process starts with main and subsequent ones start<br>
&gt; with pthread_create() but this wouldn't be a insurmountable problem.<br>
&gt; The big problem with this approach would be how to report thread<br>
&gt; identifiers in the same rank-spec as rank rank identifiers, I could<br>
&gt; revert to just using a list here but that doesn't work so well on big<br>
&gt; systems.<br>
<br>
&gt; The second option would be to treat each thread as a different entity<br>
&gt; within the rank/process and have a number of trees displayed per job,<br>
&gt; each dealing with a different thread, e.g. there would be a tree per<br>
&gt; main thread and another tree for each extra thread encountered. &nbsp;From a<br>
&gt; technical perspective implementing this would require adding a namespace<br>
&gt; to the {target_output} as it's passed back up the comms tree so is the<br>
&gt; hardest to add but would probably lead to the best solution.<br>
<br>
&gt; Finally there is the option of not showing all threads but allowing<br>
&gt; users to select a single thread per invocation of padb. &nbsp;This is the<br>
&gt; simple but functional option although might be best viewed as a step<br>
&gt; along the way to fully supporting multiple threads in future. &nbsp;Here the<br>
&gt; options are to be able to select threads by id (1,2,...) or perhaps by<br>
&gt; having a white/black list of function names that should appear in the<br>
&gt; stack for a thread before a thread is shown.<br>
<br>
&gt; I'd welcome ideas on which people would prefer or if anybody has any<br>
&gt; other thoughts on how to handle threads properly.</font>
<br>
<br>
<br><font size=2 face="Courier New">I have a support request from Bull customer that would like to have</font>
<br><font size=2 face="Courier New">padb report sorted by threads as below:</font>
<br><font size=3 face="Courier New">&nbsp; &nbsp;Thread: 1<br>
 &nbsp; --------------------------<br>
 &nbsp; [0-1999] (2000 processes)<br>
 &nbsp; ---------<br>
 &nbsp; main()<br>
 &nbsp; &nbsp;PMPI_Finalyse()<br>
 &nbsp; &nbsp; ompi_mpi_finalyze()<br>
 &nbsp; &nbsp; &nbsp;barrier()<br>
 &nbsp; &nbsp; &nbsp;----------------<br>
 &nbsp; &nbsp; &nbsp;......(249 processes)<br>
 &nbsp; &nbsp; &nbsp;---------------<br>
 &nbsp; &nbsp; &nbsp; orte_grpcomm_base_allgather()<br>
 &nbsp; &nbsp; &nbsp; &nbsp;opal_progress()<br>
 &nbsp; &nbsp; &nbsp; &nbsp; opal_event_loop()<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;epoll_dispatch()<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; epoll_wait()<br>
 &nbsp; &nbsp; &nbsp; ---------------<br>
 &nbsp; &nbsp; &nbsp; ..... &nbsp;(1751 processes)<br>
 &nbsp; &nbsp; &nbsp; ----------------<br>
 &nbsp; &nbsp; &nbsp; &nbsp;opal_progress()<br>
 &nbsp; &nbsp; &nbsp; &nbsp; opal_event_loop()<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;epoll_dispatch()<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; epoll_wait()<br>
 &nbsp; Thread: 2<br>
 &nbsp; --------------------------<br>
 &nbsp; [0-1999] (2000 processes)<br>
 &nbsp; --------- &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<br>
 &nbsp; &nbsp; &nbsp;....<br>
 &nbsp; Thread: 3<br>
 &nbsp; --------------------------<br>
 &nbsp; [0-1999] (2000 processes)<br>
 &nbsp; --------- &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<br>
 &nbsp; &nbsp; &nbsp;....<br>
</font>
<br><font size=2 face="Courier New">This report should be by job. Would you accept it ?</font>
<br>
<br><font size=2 face="Courier New">Thipadin.</font>
<br>
<br>
<br>