rts: don't define RTS_USER_SIGNALS when signal.h is not present

In the rts, we have a RTS_USER_SIGNALS macro, and most signal-related
logic is guarded with RTS_USER_SIGNALS. This patch extends the range
of code guarded with RTS_USER_SIGNALS, and define RTS_USER_SIGNALS iff
signal.h is actually detected by autoconf. This is required for
wasm32-wasi to work, which lacks signals.

1 files changed, 25 insertions, 0 deletions

diff --git a/rts/include/rts/Config.h b/rts/include/rts/Config.h
index c5f34638e0..0f923205f5 100644
--- a/rts/include/rts/Config.h
+++ b/rts/include/rts/Config.h
@@ -44,7 +44,32 @@
    Signals - supported on non-PAR versions of the runtime.  See RtsSignals.h.
    -------------------------------------------------------------------------- */
 
+/*
+Note [Lack of signals on wasm32-wasi]
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+In the wasm32-wasi spec, there is no process/thread model, no
+preemptive execution, and no posix-style asynchronous signals. See
+WASI ticket #166 for upstream discussion about signal handling.
+
+In wasi-libc, signal.h includes an #error pragma in the default
+setting that says: "wasm lacks signal support; to enable minimal
+signal emulation, compile with -D_WASI_EMULATED_SIGNAL and link with
+-lwasi-emulated-signal". It is possible to enable these flags when
+configuring wasm32-wasi-ghc, but it still makes little sense, since
+the emulation is really primitive and we might as well just stop
+pretending signals exist at all.
+
+Therefore, in the entire GHC tree, whenever we define functionality
+related to posix signals, we should add the CPP guards. When the
+target lacks signals, we can't set signal handlers at all, and raising
+a signal should degrade to exiting with the signal number as the exit
+code.
+*/
+
+#if defined(HAVE_SIGNAL_H)
 #define RTS_USER_SIGNALS 1
+#endif
 
 /* Profile spin locks */