Experimental Physics and
Industrial Control System

"Mark Rivers" <[email protected]> · Thu, 17 Feb 2011 20:46:20 -0600

Hi Jeff,

I believe the signal in question is delivered to all threads, hence the messages coming from CA.  Here is some information I found about the Posix timer functions on the opensourceproject.org.cn Website:

**********************************************

The Linux kernel implements the POSIX timers by means of dynamic timers. Thus, they are similar to the traditional ITIMER_REAL interval timers we described in the previous section. POSIX timers, however, are much more flexible and reliable than traditional interval timers. A couple of significant differences between them are:

*	When a traditional interval timer decays, the kernel always sends a SIGALRM signal to the process that activated the timer. Instead, when a POSIX timer decays, the kernel can send every kind of signal, either to the whole multithreaded application or to a single specified thread. The kernel can also force the execution of a notifier function in a thread of the application, or it can even do nothing (it is up to a User Mode library to handle the event).

*	If a traditional interval timer decays many times but the User Mode process cannot receive the SIGALRM signal (for instance because the signal is blocked or the process is not running), only the first signal is received: all other occurrences of SIGALRM are lost. The same holds for POSIX timers, but the process can invoke the timer_getoverrun( ) system call to get the number of times the timer decayed since the generation of the first signal.

**********************************************

So it sounds like Posix timers can send the signal to just a single thread, but it looks like in this case they are sending it to all threads
<https://carsmail1.cars.aps.anl.gov/exchange/rivers/Drafts/RE:%20GigE%20cameras%20stops.EML/31071535.html> 

Mark

________________________________

From: [email protected] on behalf of Jeff Hill
Sent: Thu 2/17/2011 6:36 PM
To: 'Eric Norum'; 'Bruce Hill'
Cc: 'Stoffel, Pavel'; 'EPICS Tech Talk'
Subject: RE: GigE cameras stops

Hi Eric,

> inBufClient::fillCondition
> casDGIntfIO::osdRecv ( char * pBufIn, bufSizeT size, // X aCC 361
>     fillParameter parm, bufSizeT & actualSize, caNetAddr & fromOut )
> {
> ...
> Jeff -- Is that SOCK_EWOULDBLOCK actually supposed to be SOCK_EINTR?

Negative, actually this code in src/cas (the portable server) is a single
threaded server implementation (single threaded once used to be required for
portability). That design was very dependent on non-blocking socket calls,
and therefore there was a very important test for EWOULDBLOCK on almost
every sock library call (to find out if the call is returning earlier
because it would block). This code worked correctly when interrupted by a
signal but it didn't make any attempt to suppress diagnostic messages about
such interruptions.

The EINTR errno is returned only when interrupted by a signal.

> There's similar looking code in rsrv/cast_server.c:cast_server(void
> *pParm) that has SOCK_EINTR.

So I was assuming that this was an IOC, and that this is the code that is
running.

>
> IMHO code that uses signals to get things done is inherently evil.....
>

Signals are certainly questionable in portable code, and a code that has to
be periodically handling signals would spawn off a private thread for this
purpose? Is the signal in question being delivered to all threads in the
process?

Jeff
______________________________________________________
Jeffrey O. Hill           Email        [email protected]
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

Message content: TSPA

With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead. -- RFC 1925

> -----Original Message-----
> From: Eric Norum [mailto:[email protected]]
> Sent: Thursday, February 17, 2011 4:48 PM
> To: Bruce Hill
> Cc: EPICS Tech Talk; Stoffel, Pavel; Jeff Hill; Andrew Johnson
> Subject: Re: GigE cameras stops
>
> As you mentioned, that error appears when there's a signal handler being
> run while a system call is active.   It appears that this message is
> coming from:
>
> inBufClient::fillCondition
> casDGIntfIO::osdRecv ( char * pBufIn, bufSizeT size, // X aCC 361
>     fillParameter parm, bufSizeT & actualSize, caNetAddr & fromOut )
> {
>     int status;
>     osiSocklen_t addrSize;
>     sockaddr addr;
>     SOCKET sockThisTime;
>
>     if ( parm == fpUseBroadcastInterface ) {
>         sockThisTime = this->bcastRecvSock;
>     }
>     else {
>         sockThisTime = this->sock;
>     }
>
>     addrSize = ( osiSocklen_t ) sizeof ( addr );
>     status = recvfrom ( sockThisTime, pBufIn, size, 0,
>                        &addr, &addrSize );
>     if ( status <= 0 ) {
>         if ( status < 0 ) {
>             if ( SOCKERRNO != SOCK_EWOULDBLOCK ) {
>                 char sockErrBuf[64];
>                 epicsSocketConvertErrnoToString ( sockErrBuf, sizeof (
> sockErrBuf ) );
>                 errlogPrintf ( "CAS: UDP recv error was \"%s\"\n",
> sockErrBuf );
>             }
>         }
>         return casFillNone;
>     }
>
>
> Jeff -- Is that SOCK_EWOULDBLOCK actually supposed to be SOCK_EINTR?
> There's similar looking code in rsrv/cast_server.c:cast_server(void
> *pParm) that has
> SOCK_EINTR.
>
> IMHO code that uses signals to get things done is inherently evil.....
>
>
> On Feb 17, 2011, at 3:31 PM, Bruce Hill wrote:
>
> > We're having a problem with 'CAS: UDP recv errors" that's causing
> > our GigE camera IOC's to stop updating images overnight.
> >
> > We're running EPICS 3.14.9, asyn R4.10.1, and areaDetector R1-2.
> >
> > When the images stop, we get these errors on our console:
> > 17_14:39:08:CAS: UDP recv error (errno=Interrupted system call)
> > 17_14:39:08:CAS: UDP recv error (errno=Interrupted system call)
> > 17_14:39:09:CAS: UDP recv error (errno=Interrupted system call)
> > ...
> > Googling "Interrupted system call" seems to indicated that repeating the
> > system call, in this case, recv_from, may be needed.   It appears that
> the CA
> > code is already doing that.
> >
> > I'm hoping that Jeff or Mark, or anyone, may have already seen this
> problem.
> > We've been working on upgrading to 3.14.11 and newer modules, so if this
> > problem has already been fixed we may just need to refocus our efforts
> on
> > the upgrade.
> >
> > Thanks,
> > - Bruce
>
> --
> Eric Norum
> [email protected]

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System