Experimental Physics and
Industrial Control System

"Mark Rivers" <[email protected]> · Mon, 20 Sep 2010 12:56:43 -0500

I am doing this from memory, so I'm not 100% sure it's all correct.

There was a change done in signal handling in 3.14.10.  

Previously EPICS installed a signal handler for SIGALARM.  This signal handler would then pass on the signal to the next signal handler in the chain.  However, there are 2 calling mechanisms for signal handlers, and EPICS was always using the older one.  The new Posix high-speed timers use SIGALARM and use the newer calling mechanism.  Thus, if a Posix timer was being used it would crash, because it was being called incorrectly.  This problem showed up with the Prosilica GigE camera library.

I initially came up with a solution to determine which calling mechanism was being used by the next signal handler in the chain, and call it correctly.  However, before the next release Andrew determined that SIGALARM signal handler was not actually required by EPICS at all, because it was only previously needed for HPUX, and that is no longer a supported architecture.  Thus, he removed the EPICS signal handler for SIGALARM completely.

There was another change in EPICS base required because of the use of SIGALARM by the new Posix timers.  That change is required because such timers can cause system functions like write(), read(), nanosleep(), etc. to return an EINTR error.  If this happens then the function must be called again until it no longer returns EINTR.  For example, this is now the Posix implementation of epicsThreadSleep in 3.14.11:

epicsShareFunc void epicsShareAPI epicsThreadSleep(double seconds)
{
    struct timespec delayTime;
    struct timespec remainingTime;
    double nanoseconds;

    delayTime.tv_sec = (time_t)seconds;
    nanoseconds = (seconds - (double)delayTime.tv_sec) *1e9;
    delayTime.tv_nsec = (long)nanoseconds;
    while (nanosleep(&delayTime, &remainingTime) == -1 &&
           errno == EINTR)
        delayTime = remainingTime;
}

It is possible there are still places in EPICS base where such changes are needed, but probably not.

I don't think the changes that were made to solve the SIGALARM problem are related to the SIGHUP problem being discussed here.

Mark

________________________________

From: Eric Norum [mailto:[email protected]]
Sent: Mon 9/20/2010 12:31 PM
To: Mark Rivers
Cc: Dmitry Teytelman; [email protected] tech-talk
Subject: Re: softIOC and SIGHUP

I have a vague recollection that we did something with signal disposition to be able to coexist with some equipment vendor libraries.   As I recall it was for some image acquisition/processing hardware that Mark Rivers was using.
Mark -- does this sound familiar to you?

On 17.09.2010 18:53, Dmitry Teytelman wrote:
> Hello all,
>
> Hello,
>
> I am running into a puzzling problem with a softIOC on Linux. The IOC
> is running on fairly standard x86 PC hardware under a custom Linux
> distribution (buildroot/busybox/uclibc/base-3.14.11). The IOC is
> normally started with /usr/bin/nohup, so that one can ssh to the unit,
> restart the IOC and disconnect. This worked very well until I've
> transitioned from older linuxthreads to NPTL. Now the IOC dies when it
> gets SIGHUP, even when started under nohup.
>
> A bit of digging showed that the IOC installs a handler and unblocks
> SIGHUP when it calls epicsSignalInstallSigHupIgnore() during iocInit.
> It seems to me it might be better to check first if SIGHUP is ignored
> and only modify settings if it isn't.
>

--
Eric Norum
[email protected]

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System