[lldb-dev] Process plugin implementation with multiple threads

[Zachary Turner]

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

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
synchronization.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20141113/7ce544a0/attachment.html>