[Lldb-commits] [PATCH] D83446: [WIP][lldb/Reproducers] Synchronize the command interpreter with asynchronous events

Thu Jul 9 13:36:36 PDT 2020

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