> On May 15, 2015, at 10:08 AM, Ilia K <ki.s...@gmail.com> wrote: > > @jingham wrote: > >> This is not going to be handled by the your "CreateProcessEventStateChanged" >> since that has no way of knowing whether the event you are emulating was >> interrupted. You also need to know whether the event was a stop & restart, >> which you don't know. > > > Agreed. I missed that. > >> I like it more than "generate random stop event" since it says exactly what >> you are doing, you are choosing to rebroadcast the last stop. > > > Yes, it's better, but I'm not sure it's a good decision. In addition, where > you want to store the last stop event? > >> An even more explicit way of doing this (though it would require a little >> side-bookkeeping that we don't currently do) would be >> SBProcess::GetStopEventForStopID(uint32_t stop_id). That might actually be >> more generally useful, though of course if it wasn't the current stop id, >> you wouldn't currently be able to reconstruct thread states and the like. >> But one of our long-term goals for lldb is to be able to store and replay >> "historical" stop events, with some API to say what you wanted to gather at >> these historical points. So it would fit in with that direction. > > > Sounds good for me. I'll try to do it. > >> What if there is a Listener fetching events, but then for some reason >> somebody beneath that Listener switches to sync mode, does some stuff that >> stops & starts the target, and then switches to async mode on the way out. >> The agent which is fetching events is going to see some stopped event with >> no corresponding running event. Depending on what the code using async does >> it could even see a bunch of these, some while the sync code is still >> working. How is it going to understand that? > > > Why it doesn't get corresponding running event?
Currently that gets swallowed when in sync mode as was intended (and as does the stop event in the normal course of things.) > >> Depending on what the code using async does it could even see a bunch of >> these, some while the sync code is still working. > > > How? The stop event can be sent only when command was executed. It will not > be sent while we are waiting when the command will be finished. In your case you only run one command, but what if the code that switched to sync mode under the covers ran a bunch of commands. In your original patch the stopped would get sent when the first command that runs the target completes, not when the entire sync session completes. Jim > > > http://reviews.llvm.org/D9371 > > EMAIL PREFERENCES > http://reviews.llvm.org/settings/panel/emailpreferences/ > > _______________________________________________ lldb-commits mailing list lldb-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
