RFC: add a mechanism to call epicsExit when signals are received

[Timothy Speight - STFC UKRI via Tech-talk <tech-talk at aps.anl.gov>]

Hi Core-devs folk,

More questions for me on this thread and safe-patterns... Dirk> I'm wondering if a cross cutting concern PR for base is due to be merged in yet, I believe it is #671 and perhaps some other associated feature fixes?

I have been working on an OceanOptics AD driver, trying to get epicsAtExit() all tied up and for when the binary gets SIGINT 2 under Linux Ubuntu24;

The Ocean HR spectrometer hardware gets a bit ugly if it's under acquisition & when our devops guy deploys it and intends to restart.  Luckily for me I can remotely reboot these through an API Digi provides for their awusb product. Also I'll put it out there, I've NOW got a nice little destructor ready to contribute back to JohnDobbins@CHESS_Cornell exit() from iocsh which tests well against the real hardware.

But it further led me to think how this well fits with EPICS itself and procserv. Ralph, yesterday taught me that you can do a clean/sure/dirty kill config with params for procserv.  Fundamentally for the st.cmd procserv spawned child its going to want to get a SIGINT2 and the built ioc respond accordingly.

I think Dirk could be under the hood for this in base atm to provide sure POSIX support?

Perhaps for the short time I could roll my own workaround: a minimal SIGINT handler signal.h an atopmic process that operates against the main() worker thread and somehow magically latches into the destructor I authored yesterday.  I've never seen anyone really deviate from the perl built main code and if I make a custom its certainly susceptible to being wiped at code compile time!

Any thoughts or updates on Linux signalling for EPICS from the devs?

Kind Regards

Tim Speight