HPC-GAP: unify signal handling with GAP (and IO package?)

[fingolfin]

HPC-GAP implements a new (compared to GAP) signal handling scheme. On the kernel side, this is code in src/hpc/threadapi.c, like e.g. FuncSIGWAIT, InitSignals, ... On the library side, see hpcgap/lib/hpc/thread.g which creates a dedicated signal handling thread:

CreateThread(function()
  local handlers;
  handlers := rec(
    SIGINT := DEFAULT_SIGINT_HANDLER,
    SIGCHLD := DEFAULT_SIGCHLD_HANDLER,
    SIGVTALRM := DEFAULT_SIGVTALRM_HANDLER,
    SIGWINCH := DEFAULT_SIGWINCH_HANDLER
  );
  while true do
    SIGWAIT(handlers);
  od;
end);

It would be good if the difference between the GAP and HPC-GAP signal handling setup were not quite as radical as it is now.

At the same time, I wonder a bit about the pseudo generality of this code: the presence of DEFAULT_SIGINT_HANDLER etc. makes it appear as if one could install a custom signal handler; but to do that, it seems one would have to somehow figure which thread is the current signal handling thread, kill that, and create a new one? At the same time, the kernel function HandleSignal which invokes the custom handler does not catch any errors, so using a custom signal handler written in GAP would be rather risky. Do we really want/need this level of generality? Perhaps we do, but then it would be kind of good to know what for, and design the whole system for that usecase, instead of writing seemingly "generic" code and then figuring out later on if it is actually helpful?!

Perhaps the approach has potential for improving the interaction between IO's child signal handlers and GAP's? @ChrisJefferson ?

Or perhaps this API is useful for libgap? @markuspf ?

Or perhaps @stevelinton or @rbehrends have specific use cases in mind?

If not, I am very much tempted to get rid of the various DEFAULT_*_HANDLERS for now, inlining them back into the code, and thus making it easier to unify the whole thing with GAP's signal handling.

[ChrisJefferson]

As you say, HPC-GAP spins up a new thread, which makes lots of things much easier (using sigwait means you don't have all the various conflicts one normally has with signals handlers in C), but requires an extra thread.

Without an extra thread, I don't think you could do something "HPC-GAP like" in GAP, as signal handlers have to be extremely trivial. I don't know if HPC-GAP needs the more clever stuff, or it could just use a signal handler more like GAP's, perhaps tied to one thread for convience.