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

[Érico Nogueira Rolim via Tech-talk <tech-talk at aps.anl.gov>]

On 6/26/26 05:12, Timothy Speight - STFC UKRI via Tech-talk wrote:

Hi Core-devs folk,

Hi Tim!

Thanks for reviving this thread :)

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.

What AD driver are you using for OceanOptics? I've recently tried https://github.com/NSLS2/OceanOptics , which is based on the SeaBreeze library, and was considering porting it to AreaDetector. I see you mentioned Cornell, and I remember coming upon a dead link to an OceanDirect-based driver of theirs; is that the one you're using?

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.

What specific signal are you thinking of using? I know of SIGINT and SIGUSR2, but not SIGINT2.

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?

I don't think there have been any updates, but I remember there were implementation suggestions for my idea. For epics-base, it would consist of launching a thread listening on an epicsEvent, which, when signaled, would call epicsExit. For a module with platform specific code, it would consist of registering signal handlers (possibly automatically or via iocsh commands) and having those signal the previously mentioned epicsEvent.

If you're keen on getting your hands a little dirty, how about we collaborate on moving this forward? Maybe start implementing the epics-base interface so we can check its suitability for the support module?

Kind Regards

Tim Speight

Cheers,

Érico

Aviso Legal: Esta mensagem e seus anexos podem conter informações confidenciais e/ou de uso restrito. Observe atentamente seu conteúdo e considere eventual consulta ao remetente antes de copiá-la, divulgá-la ou distribuí-la. Se você recebeu esta mensagem por engano, por favor avise o remetente e apague-a imediatamente.

Disclaimer: This email and its attachments may contain confidential and/or privileged information. Observe its content carefully and consider possible querying to the sender before copying, disclosing or distributing it. If you have received this email by mistake, please notify the sender and delete it immediately.