The UnixSignals class produces the array of signal numbers that it knows it doesn't want to hear about. But it has no idea how any particular Process plugin would implement ignoring those symbols. So that part belongs to the Process plugin. I suggested in a previous comment also adding a UnixSignals::NeedsUpdating, UnixSignals::SetNeedsUpdating, it seemed to me that that bit should also be managed by UnixSignals. But nobody else thought that was particularly compelling.
Jim > On Mar 6, 2017, at 4:56 PM, Greg Clayton via Phabricator > <revi...@reviews.llvm.org> wrote: > > clayborg added a comment. > > Jim Ingham said (in email): > >> I disagree. The different processes are at this point more about transport >> than about the platform details. That indicates to me that it's more likely >> that different process implementations will have different ways of >> implementing signal filtering, but the input of which signals will be >> filtered will be the same. Plus for each process the place where you would >> implement turning on and changing the filtering are the same. So it makes >> more sense to have the part that says "go do this filtering" all be in >> common code, and the particular plugins implement how to do this. > > That is fine. Seems like the UnixSignals class should be coordinating this > instead of doing it manually in the process? Seems like the UnixSignals class > should have guts here and call through to the > Process::UpdateAutomaticSignalFiltering() only if needed? > > > https://reviews.llvm.org/D30520 > > > _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
