On Wed, Sep 17, 2014 at 5:15 PM, Greg Clayton <gclay...@apple.com> wrote:
> > > On Sep 17, 2014, at 3:47 PM, Zachary Turner <ztur...@google.com> wrote: > > > > > > > > On Wed, Sep 17, 2014 at 3:11 PM, Greg Clayton <gclay...@apple.com> > wrote: > > > > 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? > > 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: > > bool HandleIsValid() const; > > and: > > bool ThreadIsRunning() const; > > 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... > 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.
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
