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