Yes formally that seems problematic. It wouldn't be a problem in practice because you should only call ResetNeedsUpdating in UpdateAutomaticSignalFiltering, and the only place where UpdateAutomaticSignalFiltering should be called is when Launching or Resuming, and you can't call either of these latter calls concurrently. So you'd just have to obey those rules, and make sure you couldn't change the state of the UnixSignals between computing the list of ignored signals and resetting NeedsUpdating, and you'd be fine.
Might be ugly to figure out how you would enforce this arrangement, however. Jim > On Mar 6, 2017, at 5:19 PM, Eugene Zemtsov <ezemt...@google.com> wrote: > > UnixSignals::NeedsUpdating() method suggests that there is always at most one > observer of changes in UnixSignals, the guys who clear the flag. Even though > it might be the case now, it still feels like a bomb waiting to explode when > another observer starts calling UnixSignals::ResetNeedsUpdating(). I wouldn't > want to introduce this limitation unless I absolutely have to. > > On Mon, Mar 6, 2017 at 5:09 PM, Jim Ingham <jing...@apple.com> wrote: > I like it in the base class and Greg was okay with that too. So let's leave > that where it is. > > The only bit of this behavior that could be moved into UnixSignals as it > seemed to me was the handling of "needs updating". I was mostly proposing > that because then you can already pass the UnixSignals into the communication > client to test that the signals get suppressed, so if the "needs updating" > was in UnixSignals you could test this part in the same way. > > So I'm not pushing hard on this change. > > Jim > > > > On Mar 6, 2017, at 5:09 PM, Eugene Zemtsov via Phabricator > > <revi...@reviews.llvm.org> wrote: > > > > eugene added a comment. > > > > UnixSignals is a nice self contained class that already does 99% of the > > work (see UnixSignals::GetFilteredSignals). I don't think we should have it > > call anybody. > > Only process knows when it is the right time to send actual QPassSignals > > packet, there is not need to somehow push this knowledge into UnixSignals. > > > > Let's just decide if UpdateAutomaticSignalFiltering() is specific enough to > > live in GDBProcess or it's generic enough to live in the base process. I'm > > fine either way. > > > > > > https://reviews.llvm.org/D30520 > > > > > > > > > > > -- > Thanks, > Eugene Zemtsov. _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
