Couple of reasons. Some can be worked around easily, others not so much. 1) We get and set thread names. std::thread has no support for this. It does allow you to get the native thread handle, but it's not clear if that maps on all platforms to the thing that you need in order to get and/or set the thread name.
2) We depend on thread cancellation, which std::thread doesn't support. 3) There are still some platforms that don't have a reasonable implementation of <thread>. MinGW64 comes to mind, but there might be others that I'm not aware of. On Thu, Sep 18, 2014 at 9:56 AM, Greg Clayton <gclay...@apple.com> wrote: > 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
