Was there a reason to not use implement HostThread with std::thread?

> On Sep 17, 2014, at 6:37 PM, Zachary Turner <ztur...@google.com> wrote:
> 
> 
> 
> 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

Reply via email to