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.<div><br></div><div>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).  </div><div><br><div class="gmail_quote">On Fri Nov 14 2014 at 10:09:33 AM Greg Clayton <<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
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.<br>
<br>
Greg<br>
<br>
> On Nov 13, 2014, at 2:57 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
><br>
> With ProcessWindows, most of the OS notifications from the process (breakpoints, thread creation, etc) are going to come in via a background thread.<br>
><br>
> The way I see this being handled in Virgile's implementation of ProcessWindows which I'm working on merging up is as follows:<br>
><br>
> 1) When events happen, put their parameters into some struct and put it in a queue<br>
> 2) Stop the process, which triggers a RefreshStateAfterStop call to the process plugin on the main thread, and then block the debugger thread.<br>
> 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.<br>
><br>
> Is there a technical reason why we have to do this with message passing and doing all the work in RefreshStateAfterStop?<br>
><br>
> 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?<br>
><br>
> 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.<br>
> ______________________________<u></u><u></u>_________________<br>
> lldb-dev mailing list<br>
> <a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailm<u></u>an/listinfo/lldb-dev</a><br>
<br>
</blockquote></div></div>