RE: asynDriver / epicsTimer bug

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

> I think, a timer should wait at least the specified amount of time, thus
> always round up to at least one tick.

When the timer is installed its absolute expiration time is recorded as an
EPICS time stamp. If the current time grows to be greater than the timer's
absolute expiration time, the timer's expiration callback is called.

> I think it is actually a problem with epicsTimer, which never expires
> for timeouts < 1/sysClkRateGet(). But I have not tested this.
> 

This appears, from a source code perspective, to be unlikely based on the
way the timer library is implemented. However, the scenario you describe
should be fairly obvious in a stack trace and I am happy to look at your
stack trace should there be evidence to the contrary.

PS: If timer expiration callbacks are not running be sure to look for a user
code that is stuck, for whatever reason, in a timer expiration callback.

Jeff

> -----Original Message-----
> From: Dirk Zimoch [mailto:dirk.zimoch@psi.ch]
> Sent: Tuesday, May 30, 2006 10:06 AM
> To: TECHTALK
> Subject: asynDriver / epicsTimer bug
> 
> 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.
> 
> Dirk
> 
> --
> Dr. Dirk Zimoch
> Swiss Light Source
> Paul Scherrer Institut
> Computing and Controls
> phone +41 56 310 5182
> fax   +41 56 310 4413