[Lldb-commits] [lldb] r296833 - Mention fetching thread lists lazily.

[Jim Ingham via lldb-commits]

Author: jingham
Date: Thu Mar  2 16:13:45 2017
New Revision: 296833

URL: http://llvm.org/viewvc/llvm-project?rev=296833&view=rev
Log:
Mention fetching thread lists lazily.

Modified:
    lldb/trunk/www/projects.html

Modified: lldb/trunk/www/projects.html
URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/www/projects.html?rev=296833&r1=296832&r2=296833&view=diff
==============================================================================
--- lldb/trunk/www/projects.html (original)
+++ lldb/trunk/www/projects.html Thu Mar  2 16:13:45 2017
@@ -200,6 +200,24 @@
                                             </li>
                             
                                             <li>
+                                              Recover thread information lazily
+                                              <p>
+                                                LLDB stores all the user intentions for a thread in the ThreadPlans stored in 
+                                                the Thread class.  That allows us to reliably implement a very natural model for
+                                                users moving through a debug session.  For example, if step-over stops at a breakpoint
+                                                in an function in a younger region of the stack, continue will complete the step-over
+                                                rather than having to manually step out.  But that means that it is important that
+                                                the Thread objects live as long as the Threads they represent.  For programs with many
+                                                threads, but only one that you are debugging, that makes stepping less efficient,
+                                                since now you have to fetch the thread list on every step or stepping doesn't work
+                                                correctly.  This is especially an issue when the threads are provided by an
+                                                Operating System plugin, where it may take non-trivial work to reconstruct the 
+                                                thread list.  It would be better to fetch threads lazily but keep "unseen" threads in 
+                                                a holding area, and only retire them when we know we've fetched the whole thread list
+                                                and ensured they are no longer alive.
+                                              </p>
+                                            </li>
+                                            <li>
                                               Add an extension point in the breakpoint search machinery.
                                               <p>
                                                 This would allow highly customizable, algorithmic breakpoint types, like "break on every