[lldb-dev] Process plugin implementation with multiple threads

Zachary Turner zturner at google.com
Thu Nov 13 14:57:25 PST 2014

With ProcessWindows, most of the OS notifications from the process
(breakpoints, thread creation, etc) are going to come in via a background

The way I see this being handled in Virgile's implementation of
ProcessWindows which I'm working on merging up is as follows:

1) When events happen, put their parameters into some struct and put it in
a queue
2) Stop the process, which triggers a RefreshStateAfterStop call to the
process plugin on the main thread, and then block the debugger thread.
3) In RefreshStateAfterStop, process the message that was put onto the
queue, update the thread list, etc, and then signal the debugger thread to
wake up.

Is there a technical reason why we have to do this with message passing and
doing all the work in RefreshStateAfterStop?

For example, suppose we get a create thread notification.  Shouldn't it
just be possible to acquire the thread list's mutex and stick the new
thread onto the end of it without the message passing and all that?  Why do
all threads have to stop just because one new thread was created?

Is this necessary for some reason common to all plugins and platforms, or
is it something specific to the implementation here, and there's no
underlying fundamental reason why it shouldn't work with the right
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20141113/7ce544a0/attachment.html>

More information about the lldb-dev mailing list