EPICS Home

Experimental Physics and Industrial Control System


 
1994  1995  1996  1997  1998  <1999>  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  <1999>  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>
Subject: RE: fdManager.cc question
From: [email protected] (Jeff Hill)
To: <[email protected]>
Cc: <[email protected]>
Date: Tue, 7 Sep 1999 16:17:51 -0600 
Stephanie, 

> 
> This was exactly how I fixed it to begin with but then discovered that I
> got into an infinite loop where select would always return a bad status
> complaining about a bad file-descriptor.  Zeroing the fd sets on 
> bad status
> got rid of this problem.  But I'll continue to watch out for it.

I don't think that select() will complain if a valid socket (which
has not been closed) is used. Since there is an FD_CLR() in
fdManager::removeReg() which is called by the fdReg destructor,
then the bit in the file descriptor mask will be properly cleared 
as long as the fdReg object is destroyed by the application whenever 
the corresponding socket is closed by the application.

It is possible that select() could return frequently with 
SOCKERRNO == SOCK_EINTR if there are UNIX signals in use. Therefore,
I am somewhat reluctant to add the FD_ZERO() that you suggest
because this introduces considerable overhead looping through
three potentially large file descriptor mask sets.
Even if I add the code that you suggest, there will still be
trouble if the fdReg object persists after the file descriptor 
has been closed because I loop through the installed 
fdReg objects and set the corresponding bits in the masks in
fdManager::process() just before select() is called.

In summary:
If you are creating fdReg objects then be careful that they
are always deleted when the file descriptor is closed. Otherwise,
this must be originating from the server library (a
quick look at the current source does not reveal any
obvious cause). Let me know if the problem persists.

Jeff
References:
Re: fdManager.cc question saa
Navigate by Date:
Prev: Re: IOC Benjamin Franksen
Next: RE: One CA server question Jeff Hill
Index: 1994  1995  1996  1997  1998  <1999>  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: fdManager.cc question saa
Next: Tornado on HPUX - Base config bug Ralph Lange
Index: 1994  1995  1996  1997  1998  <1999>  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024