Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Fri, 8 Jun 2012 10:49:40 -0500

Hi All,

I agree with Kay, that we have two different scenarios here and as a result we 
need two different APIs.  I also agree with Eric and Ralph that the basic 
epicsThreadSleep() should follow the other implementations and *never* return 
earlier than the requested time period.  For example:

   nanosleep()  suspends the execution of the calling thread until either
   at least the time specified in *req has elapsed, ...

   The usleep() function suspends execution of the calling process for (at
   least) usec microseconds.  The sleep may be lengthened slightly by any
   system activity or by the time spent processing the call or by the
   granularity of system timers.

I have no problem with the idea of adding another routine that tries to 
maintain a long-term processing period.  However the scan threads do not use 
epicsThreadSleep() for this anyway, they call epicsEventWaitWithTimeout() 
because they need to be able to stop immediately when the IOC gets shut down, 
so this API also needs to accept an epicsEventId and to be able to tell the 
caller when it returns whether it's because of the timer or the event.

BTW, the CA client API should also provide a version of ca_pend_event() that 
takes an epicsEventId for similar almost-immediate shutdown purposes.

- Andrew

On 2012-06-08 Kasemir, Kay wrote:
> I think Ralph's example of how 'sleep' is used is correct.
> Must sleep at least as long as requested.
> 
> What Jeff describes is a periodic timer.
> 
> The Java Timer class nicely offers both, allowing to
> a) schedule a task after some delay, with at least that delay
> b) schedule a periodic task, where the period between invocations might be
> 'squeezed' to achieve statistical correctness in the long run
> 
> 
> These are different scenarios, and one epicsThreadSleep() can't do both.
> The name epicsThreadSleep suggests to me that it's meant to be used for
> the 'sleep', not for scheduling a periodic task.
> That would require a different API like
> 
> epicsThreadPeriodic(...)

-- 
Never interrupt your enemy when he is making a mistake.
-- Napoleon Bonaparte

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System