[lldb-dev] Process plugin implementation with multiple threads

[Zachary Turner]

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).

On Fri Nov 14 2014 at 10:09:33 AM Greg Clayton <gclayton at apple.com> wrote:

> I can't say anything for windows, but if you don't need to do anything
> with threads as they are created, then you can just wait until you stop to
> discover them all. Linux has a unique problem in that it must attach to
> each thread as they are created in order to be able to get exceptions for
> that thread, so they must be notified of threads being created and do the
> attach. There should be no event for this if the process doesn't stop. For
> MacOSX, we connect to the task which is akin to the process and we don't
> need to be notified when threads are created as we can ask a task for its
> threads. MacOSX doesn't need to do anything to the threads as they are
> created, so we can just ask the task for its threads when we stop.
>
> What is the story for windows? Does the process plug-in need to attach to
> each thread as they are created? Even if it does, there should be no LLDB
> event that is required for thread creation.
>
> Greg
>
> > On Nov 13, 2014, at 2:57 PM, Zachary Turner <zturner at google.com> wrote:
> >
> > 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.
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20141114/4dd9fe95/attachment.html>