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
