Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Thu, 14 Jun 2012 12:58:16 +0200

On Thursday, June 14, 2012, Ralph Lange wrote:
> On 14.06.2012 04:19, Eric Norum wrote:
> > I think that epicsThreadSleep(x) should guarantee to return only after
> > at least x seconds have elapsed. This is in line with the semantics of
> > every other implementation of similar functions of which I'm aware.
> 
> And it does!
> 
> There are two separate issues.
> 
> 1) Jeff's C++ epicsTimer compensates by subtracting half a quantum.
> IMHO, this API should be changed to that the client can select between
> "round-up" and "round" behavior, making "round-up" the default. As an
> API change, that should go to 3.15

For 3.14 we could offer "round up" as a non-default option. But this is not 
essential, as this behaviour can be had by adding 0.5 to the delay.

> Jeff is right that I do not like the idea of changing the rounding
> behavior over the range of possible delays. That would obscure the spec,
> confuse the user, and introduce OS-implementation dependent behavior in
> the OS-independent part of libCom. 

+1

> I'd rather let 3.14 live with the
> current state, and document it.

> 
> 2) Some (=many) epicsThreadSleep(x) implementations do not work as
> defined and advertised, by calling the OS for a 1-quantum sleep even for
> a requested sleep of zero. Making the behavior consistent and to spec is
> a fix that goes into 3.14 and up.

+1

> Note that 2) does not make epicsThreadSleep(x) return early!

To clarify: it will return earlier than it does now, but not earlier than 
specified.

Just my 2 cents.

Cheers
Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System