[lldb-dev] Process plugin implementation with multiple threads

[Zachary Turner]

The way Windows debug notifications work is like this:

while (WaitForDebugEvent(&event))   // Block until something happens in the
process
{
   // Windows stopped the process for us automatically.  Do something with
the event

   ContinueDebugEvent(&event);  // Resume the process
}

After WaitForDebugEvent and before I call ContinueDebugEvent, the event
might say that a new thread was created.  So at this point I'd like to
update the thread list.  The process is actually stopped here, but it
shouldn't appear so to the user. So at the beginning I tell LLDB the
process is stopped -- SetPrivateState(eStateStopped), and at the end I tell
it that it's running again -- SetPrivateState(eStateRunning).

However, this code is still running on a different from what LLDB is going
to invoke methods on the plugin.  RefreshStateAfterStop, DoResume, etc are
all going to be running on a different thread from this loop.  The code is
simpler if I can just stick the new thread in the ThreadList (or whatever
other state needs updating if it's not thread related) right here from this
thread.  Alternatively, when I set the state to eStateStopped presumably
that will trigger LLDB to call RefreshStateAfterStop() from the other
thread.  I can also modify the state then, it just requiers a little extra
work as I have to do some synchronization and marshalling / storage of the
event parameters.

On Fri Nov 14 2014 at 2:53:35 PM Greg Clayton <gclayton at apple.com> wrote:

>
> > On Nov 14, 2014, at 10:15 AM, Zachary Turner <zturner at google.com> wrote:
> >
> > Windows doesn't need to do anything special for each thread as it is
> created. Only need to update the thread list in the Process object as far
> as we're concerned, but that's it.
> >
> > The main thing I'm worried about is that the Process object itself runs
> a couple of threads in the background (the private state thread, for
> example), so I was worried about possible race conditions when modifying
> state asynchronously (i.e. from my debugger thread).
>
> What state needs to be updated asynchronously? You shouldn't be touching
> the thread list (no need to update it, you should be able to update it on
> demand each time you actually stop right?) at all until you have a valid
> stop reason and then the process will update the threads itself when and if
> it needs them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20141114/23a5a878/attachment.html>