On Mon, Feb 12, 2018 at 3:23 PM, Ortmann, Michael
<m.ortm...@lxinstruments.com> wrote:
> I'm not sure. The last sigprocmask call restores the original signal mask of 
> the thread.
> It looks kind of pointless since the two blocked signals are unblocked by the 
> sigprocmask(SIG_UNBLOCK) call in the next loop iteration.
> The comment added in the iputils code talks about signal mask inheritance. In 
> my case arping was called via system() from a boost io_service thread for 
> which most signals were blocked. At least the SIG_UNBLOCK before recvfrom 
> makes sense in this case.

Expect many other programs to get confused in such a case.

> Since I don't know the consequences of removing that last sigprocmask() call 
> I would let it stay like in the iputils arping at GitHub.

I deleted it since now it's superfluous.
busybox mailing list

Reply via email to