On Mon, Jun 3, 2019 at 1:48 PM Niall Douglas <s_sourceforge_at_[hidden]>
wrote:

> On 02/06/2019 21:43, JF Bastien wrote:
> > This is probably the best starting point, even if not that great:
> >
> https://codesearch.isocpp.org/cgi-bin/cgi_ppsearch?q=signal&search=Search
>
> I spent some time trawling through the source codes of various results
> returned by that index, and I would categorise the use cases of signal()
> thusly, in order of common use:
>
> 1. Convenience default parametered overload for sigaction(), which is
> fiddly to call. You can tell this code by people intermixing sigaction()
> and signal() in order to save typing boilerplate for sigaction().
>
> 2. Specific use of signal() with POSIX semantics i.e. one of the
> optional choice of semantics in the C and C++ standards. These were
> overwhelmingly crash dumpers saving out extra metadata with the core dump.
>
> 3. Fallback when sigaction() is not available.
>
> 4. Specific support for Win32, with domain knowledge of Win32's
> historically awful signal() implementation baked into the source code. I
> can only assume that the author could not, or would not, use Win32 SEH.
>
> 5. "Portable" code for when not on POSIX. I noticed in the three
> examples or so of this which I found that the author specifically
> assumes that non-POSIX signal() has POSIX semantics, and not the
> extremely restricted portable semantics permitted by the C and C++
> standards. I would suggest that such code was written for completeness,
> and not actually used.
>
>
> Finally there were quite a few colourful source code comments about how
> broken signal() is, specifically the problem that when signal() handlers
> are invoked, the implementation may, or may *not*, reset the signal
> handler to default, thus causing a small window of time before you can
> reset the handler when your program may terminate. Which ruins the
> entire point of signal handling, which is to make more reliable software.
>
> Incidentally, until POSIX.2017, it was not permitted to ever call
> signal() in a multithreaded program. It is still explicitly not
> permitted by the C and C++ standards, in fact it is *required* that the
> implementation ignores signal() in a multithreaded program according to
> the current C2x working draft. I can't think of any implementation which
> conforms to that requirement however.
>
>
> Given all of the above, I think that I shall redraft my proposal paper
> to rock on and propose a complete replacement for <csignal>. Or, rather,
> programs get a choice: (i) use <csignal> OR (ii) use the new facilities,
> with it being UB if a program ever uses both for the same signal number
> at the same time.
>
> Thanks for your feedback everyone.
>

Really interesting breakdown, thanks for going through it. Can you provide
links to each of the categories above (in your updated paper)?

I'm interested in seeing what you suggest w.r.t. multithreaded. Or rather,
which of signal's problems you fix (and how), and which remain (and why).