g+
g+ Communities
Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  Index 2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014 
<== Date ==> <== Thread ==>

Subject: SIGALRM => SIGUSR1?
From: Andrew Johnson <anj@aps.anl.gov>
To: Jeff Hill <johill@lanl.gov>
Cc: Core-Talk <Core-Talk@aps.anl.gov>
Date: Wed, 11 Mar 2009 16:43:24 -0600
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  <20092010  2011  2012  2013  2014 
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  <20092010  2011  2012  2013  2014 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICSv4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·