Experimental Physics and
Industrial Control System

Ralph Lange <[email protected]> · Thu, 12 Mar 2009 12:50:48 +0100

Note that we dropped HP-UX support starting with 3.14.9 - this cuts #3

in half.

Ralph

On 11.03.2009 23:43 Andrew Johnson wrote:

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System