<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 17, 2014 at 5:15 PM, Greg Clayton <span dir="ltr"><<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
> On Sep 17, 2014, at 3:47 PM, Zachary Turner <<a href="mailto:zturner@google.com">zturner@google.com</a>> wrote:<br>
><br>
><br>
><br>
> On Wed, Sep 17, 2014 at 3:11 PM, Greg Clayton <<a href="mailto:gclayton@apple.com">gclayton@apple.com</a>> wrote:<br></div></div><span class="">
><br>
> Thinking about this, I kind of agree with you.  In fixing up the code to use HostThread, I actually didn't notice anywhere where we care about anything other than whether or not the thread is running.  So the other states don't seem to be that useful in practice.  But is IsValid() really what we want to check?  We really want to check if the thread is running.  We own the thread routine because it's the ThreadCreateTrampoline.  Can't we detect this by just having the HostThread look at the value of a shared variable?<br>
<br>
</span>We can add support to HostThread for threads we start via the HostThread interface. For others we might need to still be able to interact with another thread, but it might not have the abilities that the other threads do have. Is this is the case we might want:<br>
<br>
bool HandleIsValid() const;<br>
<br>
and:<br>
<br>
bool ThreadIsRunning() const;<br>
<br>
We might not be able to tell if a thread is running if we didn't launch the thread through the host layer though, so I am not sure if we would return true or false for that...<br></blockquote><div><br></div><div>I almost think we shouldn't support threads that we didn't create ourselves.  This models the way std::thread behaves, and also covers I believe 100% of LLDB's existing use cases anyway (can't speak for any out-of-tree code you might have though, so let me know if that assumption is wrong).  The only exception is operations on pthread_self(), which is covered by a different class called ThisThread which was submitted as part of the same refactor.</div><div><br></div></div></div></div>