Experimental Physics and Industrial Control System
Hi Jeff,
Mark Rivers is having problems integrating a third-party library into his IOCs
because it uses a Posix 1.b interval timer API which is implemented using
SIGALRM. It unfortunately also results in various system calls terminating
prematurely with EINTR, but it seems that there were only a couple of places
that we have already fixed up for that.
We currently have code that registers an sa_handler(int) for SIGALRM, which
appears to be needed on hpux but nowhere else. Unfortunately our wrapper
code doesn't work with the posix timer library on Linux because that uses the
3-argument form, registering a sa_sigaction(int, siginfo_t *, void *) routine
and when we call it with just one argument it dies.
Mark has already proved that when he removes our code that registers the
SIGALRM handler, the vendor library works quite happily. I'm guessing that
the only reason we catch SIGALRM is in case we need to use it for the system
call interrupt mechanism.
There are several possible solutions that I can see
1. Change our code to register a 3-argument sa_sigaction routine instead,
using the SA_SIGINFO bit in sa_flags to determine which type of routine we
wrapped and hence how to call it. Mark has just proved that this fixes the
problem as well, although his implementation is incomplete.
2. Switch from SIGALRM to using another signal, such as SIGUSR1. I don't know
whether this will interrupt a blocking system call, although I don't see why
it shouldn't.
3. Drop the SigAlarmIgnore code from osi/os/posix/osdSignal.cpp but provide a
copy of the version with SIGALRM support in osi/os/hpux.
4. Make the calls to epicsSignalInstallSigAlarmIgnore() conditional on the
return value from epicsSocketSystemCallInterruptMechanismQuery() being
esscimqi_socketSigAlarmRequired.
#3 is probably the least work. #2 might seem simplest but our enum is named
esscimqi_socketSigAlarmRequired and using that name with a different signal
would be misleading. Mark is probably going to prove that #1 works, but I'm
not sure that we should be registering a signal handler that we don't need,
so whatever we pick, I'd also like to do #4 as well.
This was originally your code, do you want me to fix it?
- Andrew
--
The best FOSS code is written to be read by other humans -- Harold Welte
- Replies:
- Re: SIGALRM => SIGUSR1? Ralph Lange
- RE: SIGALRM => SIGUSR1? Jeff Hill
- Navigate by Date:
- Prev:
Re: Local CA out links broken during PINI Schoeneburg, Bernd
- Next:
Re: SIGALRM => SIGUSR1? Ralph Lange
- Index:
2002
2003
2004
2005
2006
2007
2008
<2009>
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Local CA out links broken during PINI Tim Mooney
- Next:
Re: SIGALRM => SIGUSR1? Ralph Lange
- Index:
2002
2003
2004
2005
2006
2007
2008
<2009>
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024