On 30/05/2019 19:23, JF Bastien wrote:
> I think this is a generally useful thing to explore, but it definitely
> needs to go through SG1 first because it affects the memory model.
> SG1 spends a considerable fraction of its time pondering the progress
> guarantees around signal handling, and it interacts with all the SG1
> facilities in a pretty deep way (e..g: lock-freedom).

Well, okay. But no magic is being done here. It's mostly a much more
convenient wrapper of <csignal>.

> I'd like to understand the discussion of setjmp/longjmp. Why not talk
> about sigsetjmp/siglongjmp instead? They're primitives built for this
> purpose, whereas setjmp/longjmp aren't.

The reference implementation doesn't use sigsetjmp/siglongjmp. And the
current C++ standard only has setjmp/longjmp in any case.

(To expand on this, the reference implementation once upon a time did
use sigsetjmp/siglongjmp. They have really bad performance. So, a lot of
careful refactoring was done to eliminate needing to use them)

> Right now signal supports SIGABRT, SIGFPE, SIGILL, SIGINT, SIGSEGV,
> SIGTERM. You're expanding that list. It would be good to discuss this
> expansion, as well as how your proposal interacts with existing signal
> support.

I have added a FAQ item answering this question, which is as follows:

\texttt{<csignal>} already defines the Process abort, Illegal
instruction, Process interruption, Segmentation fault, and Floating
point error signals. To those, this proposal adds:

\begin{enumerate}
    \item Undefined memory access (\texttt{SIGBUS})

    Why? Segmentation faults occur when a program tries to access memory
whose permissions do not permit that access. Bus errors occur when a
program tries to access memory in a way which is not possible e.g.
reading or writing an aligned object not at its proper alignment, or an
address range for which there are literally no lines in the address bus
in the hardware. This is subtly different to \texttt{SIGSEGV}, and I
think it worth standardising support for it, especially now that 64-bit
addressed systems have become so prevalent (and these often only have 48
address lines in hardware).

    \item Broken pipe (\texttt{SIGPIPE})

    Why? Making use of third party library code may require you to
enable delivery of \texttt{SIGPIPE}, because said third party library
code does not handle \texttt{EPIPE}, leaving you with zero alternative
but to use \texttt{SIGPIPE}. This has happened to this author enough
times in his career that I think it worth adding to the standard,
especially given that \texttt{SIGPIPE} has been in POSIX for nearly forever.

    It should be \textbf{stressed} that Broken pipe can be permitted to
be meaningless on any particular implementation of C++. It is more a
case of `if your platform might send a Broken Pipe unanticipated
interruption, you can use this to recover from it'.
\end{enumerate}

(Apologies for pasting LaTeX)

Niall