Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  <19992000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  Index 1994  1995  1996  1997  1998  <19992000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019 
<== Date ==> <== Thread ==>

Subject: RE: fdManager.cc question
From: johill@lanl.gov (Jeff Hill)
To: <saa@slac.stanford.edu>
Cc: "Aps. Anl. Gov" <tech-talk@epics.aps.anl.gov>
Date: Thu, 2 Sep 1999 16:29:25 -0600
Hi Stephanie,

Thanks for the tip.

> Here is a code snippet from fdManager::process:
>
>         else {
>                 status = select (this->maxFD, &this->fdSets[fdrRead],
>                         &this->fdSets[fdrWrite],
> &this->fdSets[fdrExcp], &tv);
>         }
>
>         staticTimerQueue.process();
>         if (status==0) {
>                 this->processInProg = 0;
>                 return;
>         }
>         else if (status<0) {
>                 if (SOCKERRNO == SOCK_EINTR) {
>                         this->processInProg = 0;
>                         return;
>                 }
>                 else {
>                         fprintf(stderr,
>                         "fdManager: select failed because
> errno=%d=\"%s\"\n",
>                                 SOCKERRNO, SOCKERRSTR);
>                 }
>         }
>
> If status is negative but not SOCK_EINTR, process does not return
> but goes
> on to process the fd list.

I agree that this is a bug. I fixed it in the 3.13.1 patch branch
and also on the main trunk in CVS.

	else {
		status = select (this->maxFD, &this->fdSets[fdrRead],
			&this->fdSets[fdrWrite], &this->fdSets[fdrExcp], &tv);
	}

	staticTimerQueue.process();
	if (status==0) {
		this->processInProg = 0;
		return;
	}
	else if (status<0) {
		if (SOCKERRNO != SOCK_EINTR) {
			fprintf(stderr,
			"fdManager: select failed because errno=%d=\"%s\"\n",
				SOCKERRNO, SOCKERRSTR);
		}
		this->processInProg = 0;
		return;
    }

> When I was debugging yesterday, I got a bad
> status and SOCKERRNO of 5 (I/O error) (I don't yet know why I got
> this error
> but that's not the point).  It appears that when process continued
> after the select error, it eventually got stuck in a Multinet
> call and I had
> to manually restart my PCAS.  It got stuck in the
> casDGClient::processDG fill
> call (actually in the casDGIntfIO::osdRecv recvfrom call).

If select indicates that there is UDP pending and the DG IO recv call back
is called, and there isnt UDP IO pending, then we could become temporarily
stuck
because the UDP socket isnt currently set for non-blocking IO. I consider
this to be a problem also, even if it is less severe. Since a fix for this
required large changes I made the patch which changes UDP to non-blocking IO
only on the main development trunk in CVS.

I am working my way down through my mail and hope to get to your
other messages (and many others from the rest of the collaboration) soon.

Jeff



Navigate by Date:
Prev: Re: One CA server problem saa
Next: Re: fdManager.cc question saa
Index: 1994  1995  1996  1997  1998  <19992000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019 
Navigate by Thread:
Prev: Re: One CA server problem saa
Next: Re: fdManager.cc question saa
Index: 1994  1995  1996  1997  1998  <19992000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·