I agree that the naming of these functions are suboptimal indicators of what they do.
On Mon, Jun 1, 2015 at 1:59 PM, Zachary Turner <ztur...@google.com> wrote: > Ahh, I find it a little confusing that ShouldResume() calls WillResume(). > ShouldResume() to me sounds like a function that should be const. It seems > like it should just ask a question and gets a yes/no answer, but not modify > anything. > > But looking over the code, it looks like WillResume() actually means "I > don't know if you need to resume or not, but if you do, then do it, and if > you don't, then tell me that by returning false" > > > On Mon, Jun 1, 2015 at 1:40 PM Adrian McCarthy <amcca...@google.com> > wrote: > >> ThreadList::WillResume, near the bottom, ends up calling >> ShouldResume(eStateSuspended) on the other threads, because the >> ThreadPlanStepOverBreakpoint::StopOthers says it should. >> >> Thread::ShouldResume effectively passes its parameter on to the thread's >> WillResume, with the comment, "Let Thread subclasses do any special work >> they need to prior to resuming." >> >> >> On Mon, Jun 1, 2015 at 1:30 PM, Zachary Turner <ztur...@google.com> >> wrote: >> >>> >>> >>> On Mon, Jun 1, 2015 at 1:29 PM Zachary Turner <ztur...@google.com> >>> wrote: >>> >>>> I'm not quite ready to throw the blanket over this one yet :) >>>> >>>> What was the value of resume_state when it called WillResume()? It >>>> sounds like it was eStateSuspended, which if that's the case, then it still >>>> seems like something deeper inside of LLDB's thread plans is confused about >>>> something, because calling WillResume(eStateSuspended) means "The process >>>> is seriously about to resume, and when it does, this thread is not going to >>>> remain suspended". >>>> >>> >>> s/is not going to/is going to/ >>> >> >>
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev