jingham added a comment. In D83446#2142350 <https://reviews.llvm.org/D83446#2142350>, @JDevlieghere wrote:
> In D83446#2142301 <https://reviews.llvm.org/D83446#2142301>, @jingham wrote: > > > I think the proper way to gate this sort of "race" is to use the process > > state. If the current process state is "stopped" then that means we're > > done with the stop processing and ready to allow commands that require the > > process to be stopped. > > > > When I originally did this, the plan was that the the Public state would > > not be set to stopped until the stop event was consumed by the process > > listener. So if you tried to "continue" the process before the work to > > handle the stop event was done, you would see the state as "running" and > > the continue would not succeed. > > > > However, that ran up against the problem that part of the "asynchronous" > > work that you might do on stop can involve running commands and SB API. > > Those need to see a public stop state or they won't work correctly. So the > > public state gets set to stopped too early, and then it's possible for this > > to be racy. IMO the solution to this problem should be for the Event > > Handler to be able to run its commands "as if" the public state were > > stopped, but everybody else who is trying to run commands will still see it > > as running. Then when the event handler is done with it's job, the process > > Public state is switched to stopped, and now commands coming from other > > sources will run in the stopped state. > > > How would that work with the reproducer issue? How would you prevent the > command interpreter from processing the next command before the event handler > thread issues the process info packet? Sorry, I think these issues are orthogonal. I was mostly responding to Pavel's comments. Repository: rLLDB LLDB CHANGES SINCE LAST ACTION https://reviews.llvm.org/D83446/new/ https://reviews.llvm.org/D83446 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
