#740 Unsafe signal handlers

[dkl]

The rtlib's SIGINT/SIGSEGV/etc. signal handling (src/rtlib/signals.c:gen_handler()) is unsafe because it uses functions that are not async-signal-safe.

gen_handler() -> fb_End() -> exit() -> global destructors, including fb_hRtExit() -> fb_hEnd() ...

The Unix specific code in src/rtlib/unix/hinit.c has a signal_handler() which also calls fb_hEnd() (in fact it seems to be duplicating the signal handling code from src/rtlib/signals.c, more or less).

Calling fb_End()/fb_hEnd() in order to do exit the rtlib "nicely" means using all kinds of functions that cannot safely be used from a signal handler. On Unix for example we're using pthread_* functions which aren't safe from signal handlers. I think similar issues exist for Win32.

This issue was fixed for the SIGWINCH handling in the Unix rtlib in commit [813d0d]. Basically the only safe thing we can do from a signal handler is to set a flag or call _Exit() (exit process without running global destructors).

Why do we even need to handle SIGINT/SIGSEGV/etc.?

If compiling with -e, we call fb_InitSignals() to enable the signal handling from src/rtlib/signals.c. It prints a "nice" error message such as Aborting due to runtime error 12 ("segmentation violation" signal) and invokes ON ERROR handlers.

On Unix, the signal handlers are also used in order to restore terminal state (such as echoing) on exit.

I don't think we'd just want to drop these features (especially restoring terminal state on Unix seems pretty important to me), but then the question becomes how can they be implemented by using only async-signal-safe functions.