What would happen if there was a Haskell process that ran as a dispatcher/telephone exchange? If this received a message from a C process and then sent the signal, wouldn't this work?
What problem do you think this is solving? Because it isn't solving the problem with the Haskell runtime being unable to clean up the internal state of arbitrary C code, which is the reason C code is run the way it is by most other environments.
>> Since my extensions are doing the heavy lifting, they
often run for long periods (by which I mean 10s of minutes). Meaning
the signal is ignored for long periods.<<
and you responded
>> Cross-runtime borders are *always* a problem for signals and various resources that may need to be cleaned up. <<
So if both statements are true and non-misleading, a solution with a dispatcher thread to catch messages would avoid this problem. Because there would be no cross-runtime border for signals. And the dispatcher thread could respond to messages immediately with "I'm taking responsibility for this message now" possibily simplifying the C code.
This is about OS signals, not some kind of routable or controllable messages. Your options are ignore, die, or a *single* signal handler which can only safely do a limited number of things.
In any case, the OP is looking for some kind of unwind-on-signal capability so that receipt of a signal safely aborts the C function in such a way that the Haskell or Python runtime can resume and neither memory nor resources (unclear what the hooks are doing but conceivably they could be working with files etc.) will be leaked. In practice, when a signal arrives you can't guarantee much of anything, and specifically in particular neither malloc() nor stdio are guaranteed to be consistent; if you want to recover cleanly, you can only set a flag that the main flow of execution checks regularly (or some morally equivalent mechanism; event-driven systems, including GHC's own runtime, generally write a byte down a designated pipe which is then handled by the standard event loop).
There just isn't a good way to deal with this otherwise even in an all-C system; when you're mixing disparate runtimes, it's close to impossible to handle it sanely.
Well, NOTHING Haskell could do could clean up after literally arbitrary C code! But was the OP asking that question? It would seem a rather strange one. I thought the problem was that additional complexity was being added to said clean-up was coming from the very long time required to respond to signals, and the OP was asking if there was anyway to avoid this - which is a very different question.
Only a different question if you don't have any idea what's going on...
The OP specifically noted that signals are blocked during cross-calls from Python and asked if the same is true of Haskell; the answer is yes, and also for most other runtimes. I explained *why* they are blocked. What the OP wants is for a signal to abort the C function and return control to the Haskell or Python runtime. Do you understand why this requires arbitrary cleanup capability to be safe?
(Hrm; do you understand that C doesn't have garbage collection or even reference counting, but is entirely manual resource management? I didn't explicitly say that, although what I did say should have implied it.)