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

[Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov>]

On 4/3/25 06:17, Jure Varlec via Tech-talk wrote:
> On 4/3/25 11:34, Michael Davidsaver via Tech-talk wrote:
> > wrt. your attached epicsSignalExit.cpp, the method epicsSignalExit::getInstance()
> > is not async safe since (depending on c++ version) it will run the class
> > epicsSignalExit constructor. 

To be clear, I like the idea that eg. systemd+procServ could
trigger a clean exit.  I just had a past bad experience with
a library unconditionally installing/replacing signal handlers.

fyi. have a look at epicsSignal.h for the limited management
currently possible with libCom.

> I don't think that's the case. The signal handler is run only if it is first registered using epicsExitOnSignal(), presumably from iocsh. getInstance() is first used there, which constructs the static object. The next invocation of getInstance() (from the signal handler) will not run the contructor.

True, my mistake.


> If this feels icky to you, there might be another approach. Have a global bool specifying whether this feature is enabled or not. The iocsh command then only sets this flag. Thread creation and handler registration is done at IOC init, if the flag is set.

The existing global constructors/destructors in libCom occasionally
cause problems, and I would like to see them removed.  So imo. adding
another seems counterproductive.

https://urldefense.us/v3/__https://github.com/epics-base/epics-base/issues/286__;!!G_uCfscf7eWS!dYXoRGfIz5VngL5KqDx1QwaTsAFBAWPpH_F7hMKcSH79eGAQ_GCLu55dr24IbJSnowSV9Dy2t5qHzRBIb0eGROOuVQ$ 

I suppose it might also be acceptable to install and remove
a handler with initHook callbacks.


> Érico, I don't have the time right now to look deeper into this, but I would love to see something like this because it would make managing IOCs via Systemd more straightforward, not to mention making compulsive use of C-c to terminate IOCs nicer. Thanks for pushing this forward!

For reference, compulsive use of ctrl+d has this effect today.
(closing stdin triggers a return from "iocsh(NULL)" )

It might be fun to teach procServ to try this before signaling.


Also, I recall that the linux-specific "prctl(PR_SET_PDEATHSIG, ...)"
has be used to build cleanup on exit mechanisms which work even
for abnormal termination.