RE: GigE cameras stops

["Jeff Hill" <johill@lanl.gov>]

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        johill@lanl.gov
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:wenorum@lbl.gov]
> 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
> wenorum@lbl.gov