[lldb-dev] Process spawning and shutdown
Zachary Turner
zturner at google.com
Wed Sep 17 18:37:34 PDT 2014
On Wed, Sep 17, 2014 at 5:15 PM, Greg Clayton <gclayton at apple.com> wrote:
>
> > On Sep 17, 2014, at 3:47 PM, Zachary Turner <zturner at google.com> wrote:
> >
> >
> >
> > On Wed, Sep 17, 2014 at 3:11 PM, Greg Clayton <gclayton at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140917/fc5d7519/attachment.html>
More information about the lldb-dev
mailing list