"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.
I think the topic is moving in the right direction with cleaner code
than the previous round. Thanks for investing time in it.
