On Sat, 2018-03-03 at 00:16 +0100, Martin Wilck wrote: > On Fri, 2018-03-02 at 22:23 +0000, Bart Van Assche wrote: > > On Fri, 2018-03-02 at 23:15 +0100, Martin Wilck wrote: > > > On Fri, 2018-03-02 at 21:35 +0000, Bart Van Assche wrote: > > > > This change looks more complicated to me than necessary. Have you > > > > considered > > > > to pass an empty signal set as the fourth ppoll() argument? > > > > > > An empty set would mean that no signal is blocked during ppoll(). > > > Therefore e.g. SIGALRM would terminate multipathd if it arrives > > > during the ppoll (no handler set, and default action is "Term"). > > > > Have you considered to only block SIGALRM while ppoll() is in > > progress? > > Why should we? The same reasoning applies to other signals such as e.g. > SIGUSR2. We need to block all signals except those that we can handle. I see two reasons: - All signals that are delivered to the multipathd process except SIGALRM should interrupt ppoll(). SIGPIPE is delivered to the thread that caused that signal to be raised. SIGUSR2 is sent to a specific thread. Hence neither SIGPIPE nor SIGUSR2 will ever be delivered to the thread that calls ppoll(). - Asking ppoll() to block all signals is weird because some signals, e.g. SIGKILL and SIGSTOP, cannot be blocked. Bart. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
