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
Well the OP wrote 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. Or the C code has to send signals, then wouldn't it be possible for a dispatcher thread to catch them, and wouldn't that simplify architecture?
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.
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.