What is duktape's policy when receiving signals?

I’m curious about correctly writing an FFI to duktape from GHC Haskell. There are other Haskell bindings, but I’m not sure whether they’re correct or just coincidentally working OK. I don’t have much experience with signal handling in C, so I’m going off what I’ve read.

The RTS uses signals to trigger context switches and other threading features. In particular, using the system timers API, SIGVTALRM will be triggered on a regular basis. The C code being called apparently needs to be aware of this.

I believe it’s possible for me to write some small wrapper C code to register a signal mask to prevent these signals from bothering the duktape functions.

---

Secondly, when declaring a foreign function, I can choose whether it is interruptible or not. If I mark it interruptible, that means that if I terminate the Haskell (green) thread using regular Haskell code, SIGPIPE will be signalled to the OS thread (see also). What does duktape do when it receives SIGPIPE, and SIGINT for that matter? Is it manifested as a JS exception? What’s the relationship between “protected” functions and non-protected ones in this setting? I’ve read through the user guide a few times, but wasn’t able to find clarity on this.

---

Use-case: I’d like to be able to execute PureScript from my Haskell code to have server-side rendering and validation as well as front-end. I want to do one-shot runs of code. Ideally I could execute the JS via duktape, which has fine-grained control over what functionality is available (e.g. I need timers API (setTimeout, used for asynchronous runs by a library I’m using, but not actual waiting), but not I/O).

However, due to the messiness in dealing with GHC’s RTS, I’m wondering whether correctness-wise it may be easier to launch a nodejs program as a pipe and parse JSON output? 🤔 But then you have a much heavier dependency that needs to be kept around somewhere to be launched, etc. Trade-offs.

[svaarala]

The interrupt check is really quite simple at present and there has been no thought about executing Duktape calls within the interrupt check.

But, I think calling a function from the interrupt check should work fine because a function may be get called for various other reasons within the bytecode executor - e.g. a property read may invoke a Proxy trap, and the bytecode executor is generally unaware of the situation.

If this doesn’t work, it should be relatively easy to fix because the executor must tolerate recursive calls elsewhere.

[aksyom]

When the DUK_USE_EXEC_TIMEOUT_CHECK -macro is executed by the bytecode executor, is it safe to call a global function object within the duk_context being interrupted?

If it is not safe to call a function, would it be safe to modify a global value within the duk_context?