The stop callback is a remnant of the ThreadStateCoordinator. We don't need it now that TSC is
gone, as we know exactly which function to call when threads stop. This also removes some
stop-related functions, which were just forwarding calls to one another.
Details
Diff Detail
Event Timeline
Please see my comments.
source/Plugins/Process/Linux/NativeProcessLinux.cpp | ||
---|---|---|
4537 | Please add a new ThreadContext constructor that takes ThreadState parameter. | |
4543 | If RequestThreadStop fails is it necessary to call m_pending_notification_up->wait_for_stop_tids.insert(tid); ? | |
4544 | Do we need to stop main thread of lldb-server here or RequestThreadStop(tid,.. ) ? |
source/Plugins/Process/Linux/NativeProcessLinux.cpp | ||
---|---|---|
4537 | Done. | |
4543 | I would leave this as-is, for now at least, as now I am trying to do cleanups that don't change functionality. But let's think what are the possible reasons the tgkill may fail: If everything works as it should, a)-c) should not actually happen, since the thread should stop with PTRACE_EVENT_EXIT before this happens. At this point the thread still exists, and we can send signals to it. If we miss this event for whatever reason, and the thread is really dead, then it could happen that tgkill fails. However, we should still get WIFEXITED event, at which point we will delete the thread and fire the notification (and it wont matter whether we set the flag or not). If we don't get that event also then we will probably hang forever waiting for the thread the stop, but if we end up here, then we are probably in a deep mess anyway. What do you think? | |
4544 | Good catch. It's tid of course. |
Looks good.
source/Plugins/Process/Linux/NativeProcessLinux.cpp | ||
---|---|---|
4543 | I was thinking about possible EINTR error that tgkill may raise but it seems "man tgkill" doesn't mention such error as a possible outcome. |
Please add a new ThreadContext constructor that takes ThreadState parameter.