> I agree with Kay, that we have two different scenarios here and as a
> result we need two different APIs.
As I recall, in the current API, periodicity is determined by the return
value from the timer expire function.
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> On Behalf Of Andrew Johnson
> Sent: Friday, June 08, 2012 9:50 AM
> To: [email protected]
> Subject: Re: epicsTimer and rounding
>
> 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
- Replies:
- Re: epicsTimer and rounding Andrew Johnson
- References:
- Re: epicsTimer and rounding Kasemir, Kay
- Re: epicsTimer and rounding Andrew Johnson
- Navigate by Date:
- Prev:
Re: epicsTimer and rounding Andrew Johnson
- Next:
Re: epicsTimer and rounding Eric Norum
- Index:
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: epicsTimer and rounding Andrew Johnson
- Next:
Re: epicsTimer and rounding Andrew Johnson
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
<2012>
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|