clayborg added a comment.
> I think the real bug is in StopPrivateStateThread, which only sends the stop
> state if the thread is still joinable; since I removed the Reset, it is of
> course still joinable after it exits. But even with the Reset (which we agree
> shouldn't be there), there is still a race between the time the detach signal
> is sent and when the thread sees it and exits. It seems once a detach or stop
> is sent, no further detaches/stops can be sent, regardless of what the thread
> is doing (since it will exit as soon as it sees the first one). So there
> should be a flag to that effect somewhere checked in
> ControlPrivateStateThread. Probably all the calls to `IsJoinable()` should be
> replaced with calls to `PrivateStateThreadIsValid`, which should be updated
> to check that flag.
>
> I don't see a nice way to add this flag for each private state thread,
> though, instead of for the process object as a whole. But maybe that's all
> that's necessary?
You can just check the value of m_private_state_control_wait:
void
Process::ControlPrivateStateThread (uint32_t signal)
{
// Signal the private state thread. First we should copy this is case the
// thread starts exiting since the private state thread will NULL this out
// when it exits
HostThread private_state_thread(m_private_state_thread);
if (private_state_thread.IsJoinable() &&
m_private_state_control_wait.GetValue() == false)
{
m_private_state_control_wait is always false if the private state thread is
running. It is set to true immediately after sending a control and syncing with
the sender and then it is set back to false. It is set to true again when the
thread exits.
Repository:
rL LLVM
http://reviews.llvm.org/D19122
_______________________________________________
lldb-commits mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
