Experimental Physics and Industrial Control System
On May 30, 2006, at 11:05 AM, Dirk Zimoch wrote:
Hi Marty, Jeff et al
When asynOctet->read() (or at least readRaw() of the TCP port
driver) is called on vxWorks with pasynUser->timeout < 1/
sysClkRateGet() [normally about 16 ms], the read call hangs and
does never time out.
I think it is actually a problem with epicsTimer, which never
expires for timeouts < 1/sysClkRateGet(). But I have not tested this.
I think, a timer should wait at least the specified amount of time,
thus always round up to at least one tick.
Yes, that is what they are supposed to do. On vxWorks the code in
question is:
epicsEventWaitStatus epicsEventWaitWithTimeout(
epicsEventId id, double timeOut)
{
int status;
int ticks;
if(timeOut<=0.0) {
ticks = 0;
} else {
ticks = timeOut*sysClkRateGet();
if(ticks<=0) ticks = 1;
}
status = semTake((SEM_ID)id,ticks);
if(status==OK) return(epicsEventWaitOK);
if(errno==S_objLib_OBJ_TIMEOUT) return(epicsEventWaitTimeout);
return(epicsEventWaitError);
}
This looks correct to me.
BTW -- the latest versions of ASYN have done away with the EPICS
timers in the TCP and serial drives.
--
Eric Norum <[email protected]>
Advanced Photon Source
Argonne National Laboratory
(630) 252-4793
- References:
- asynDriver / epicsTimer bug Dirk Zimoch
- Navigate by Date:
- Prev:
asynDriver / epicsTimer bug Dirk Zimoch
- Next:
Re: about mca (from ihep in china) Carl Lionberger
- 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:
asynDriver / epicsTimer bug Dirk Zimoch
- Next:
RE: asynDriver / epicsTimer bug 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