See also https://github.com/hpcc-systems/HPCC-Platform/pull/7490

TODO: rebase against 5.4 once gets merged. Then should be ready to get PR'd.

found bug while testing

Edit: Bug was unrelated to my code. Fixed in (thor's kill_process call was using the old parameter list instead up the new one.)

Going to freeze this for a little while and wait for feedback.

https://github.com/hpcc-systems/HPCC-Platform/compare/candidate-5.4.0...Michael-Gardner:hpcc-13156-merge?expand=1

In system/jlib/jmisc.hpp we enumerate ahType with aht_terminate and aht_interrupt. These values will be our platform agnostic signal types that are then used in our abort handling code.

system/jlib/jmisc.hpp

Within system/jlib/jmisc.cpp we have two functions, WindowsAbortHandler and UnixAbortHandler that act as receivers for all the signals we will encounter. In these functions we map our platform specific signals to platform agnostic ahTypes. The receiving functions then pass the ahType into notifyOnAbort which is also platform independent. notifyOnAbort calls all of our registered signal handlers (with ahType as its parameter) in LIFO order and if a handler in the list returns true, exits the program. So now all we have to do in order to use this, is to branch our signal handling code (within dali, thor, sasha etc) depending on what agnostic handler type we receive when our handler is called.

system/jlib/jmisc.cpp

From Jake in initial PR:

It doesn't look like you've made changes for Windows, it won't compile as it is.
Am also unsure though about whether it makes sense passing the native signal values, when method is supposed to be cross-platform.
It would mean the abort handlers would now have to contain platform specific code to handle the signal types..
Perhaps would be better if prototype was something like:
enum ahType { aht_terminate, aht_interrupt, ... };
typedef bool (*AbortHandler)(ahType, long);

where 1st param was a cross-platform interpretation of event (we probably only care about terminate and interrupt). The 2nd param. was exact signal number (and platform specific).
Most (all?) of our uses wouldn't care about the 2nd param.