On Sat, Nov 5, 2022 at 1:34 PM Dmitry Goncharov <invalid.nore...@gnu.org> wrote:
> Follow-up Comment #6, bug #63307 (project make): > > > If SIGIGN was ignored before make was started though, it should remain > ignored, even for make's children, see also > <https://lists.gnu.org/archive/html/bug-make/2022-11/msg00015.html> in > reply > to Andreas Schwab's first patch. Correct me if I am wrong, but I think your > patch re-enables it in that case? > > My patch causes the disposition of sigpipe to be set to SIG_DFL in the new > process. See https://pubs.opengroup.org/onlinepubs/9699919799/, > specifically > "Signals set to be caught by the calling process image shall be set to the > default action in the new process image (see <signal.h>)." > > This desire to have the default disposition is intentional. Some of the > reasons are explained in update 2. Other reasons are the desire to avoid > complexity in make. Especially when there is no clear need for that > complexity. > This is a change in behavior: previously, make didn't alter the disposition of SIGPIPE and a build system could set it to SIG_IGN and have all the invoked recipes inherit that. As part of saying that make will ignore SIGPIPE, you've decided to impose a rule that the rest of the build system has to deal with it in the recipes instead of permitting a pass-through. That's an unnecessary and user-unfriendly imposition. In regards to the specific impl of Andreas's 2nd patch there are 2 points. > > 1. That patch fails to restore the disposition in the case of make > re-executing itself (in order to read an updated makefile). > This could be fixed by calling sigaction before execve, but that'd not be > atomic. > 2. That patch uses posix_spawnattr_setsigdefault to set the disposition > for a > child process (when make uses posix_spawn). This fails the purpose of the > patch, if make was invoked with sigpipe disposition of SIG_HOLD. > (SIG_HOLD? That's not a real disposition (in posix) but rather part of an obsolete version of a mechanism standardized as sigprocmask() and orthogonal to the disposition (ignore/default/catch).) > Fixing those deficiencies is not that cheap. In the end, i didn't see any > benefit for make to go through that trouble of restoring sigpipe > disposition > for its children and i proposed this simple fix. > > Unlike attempts to restore, one nice property of the sighandler patch is > that, > if more calls to exec are introduced to make, the patch will still work for > all of them. > Setting the disposition of SIGPIPE to be caught with a do-nothing routine is a good idea. Can you just skip that if the disposition is SIG_IGN at start? Then a SIG_IGN will be inherited but the disposition will otherwise be reset by execve.
