summaryrefslogtreecommitdiff
path: root/rts/include
diff options
context:
space:
mode:
Diffstat (limited to 'rts/include')
-rw-r--r--rts/include/rts/Config.h25
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 */