On Wed, Jun 25, 2025 at 09:07:11AM -0800, Junio C Hamano wrote: > "Carlo Marcelo Arenas Belón via GitGitGadget" > <gitgitgadget@xxxxxxxxx> writes: > > > +@@ Makefile: include shared.mak > > + # when attempting to read from an fopen'ed directory (or even to fopen > > + # it at all). > > + # > > ++# Define USE_NON_POSIX_SIGNAL if don't have support for SA_RESTART or > > ++# prefer to use ANSI C signal() over POSIX sigaction() > > ++# > > ... > > ++ifdef USE_NON_POSIX_SIGNAL > > ++ COMPAT_CFLAGS += -DUSE_NON_POSIX_SIGNAL > > ++endif > > The new symbol sounds like "POSIX does not have signal(2) but on > this platform we have a usable signal(2), so we use it here", but I > do not think that it is what we want to say (as POSIX inherits this > from ANSI C anyway). More importantly, this "USE_X" sounds as if we > allow builders to set it and magically we stop using sigaction(2), > which is not what is going on. We have tons of calls to both > signal(2) and sigaction(2), and we turn calls to signal(2) we have > in daemon.c to sigaction(2) but on some platforms their sigaction(2) > cannot do what we ask it to do, so we are stuck with signal(2) on > these platforms only for these calls in daemon.c. It may be obvious > to those who develop and review this series, but not for anybody else. > > Isn't the situation more like: > > We use sigaction(2) everywhere and have been happy with it in > our code, but this topic discovered that on some platforms, > their sigaction(2) does not do XYZ that everybody else's > sigaction(2) does, so on them we need to fall back on the plain > old signal(2) on selected code paths that we need XYZ out of the > signal handling interface. > > What is this XYZ that describes the characteristics of > signal/sigaction implementation on these platforms? A name > constructed more like SIGACTION_LACKS_XYZ (hence we have to resort > to signal), possibly with a more appropriate verb than "lack", would > be less confusing. sigaction(2) doesn't have any issues and it is indeed a better option every time as it behaves the same in all platforms that have it. the problems we have come from our codebase: 1) we have a hack to workaround the lack of support for SA_RESTART in some platforms, which sets it to 0 and allow us to compile as if it works. 2) Windows doesn't have sigaction() and their compability version needs updating if we would use it for this new code. Keeping the fallback to use signal() isn't really needed, and is indeed problematic, as it crashes in AIX and probably other SysIII derived systems because of the hack Chris described for non BSD signal(). Carlo
