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
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. 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.
Note that 2) does not make epicsThreadSleep(x) return early!
~Ralph
> On Jun 13, 2012, at 6:12 PM, Hill, Jeff wrote:
>
>> Hi Andrew, Ralph,
>>
>> We will need to decide how to proceed with the timer delay
>> compensation issue. I am extremely busy so it will be easy
>> for this to fall through the cracks.
>>
>> It occurs to me that this issue could also be fixed by just not
>> compensating the timer delay when the requested delay is less than one
>> quantum, but otherwise leaving the compensation code in place. I think
>> I mentioned that option before, but I suspect that Ralph is in favor only
>> of a solution that 100% removes the compensation. I mention this
>> option again only because it would be easier to justify as a backwards
>> compatible bug fix, and therefore as an R3.14 patch. I believe that
>> Andrew is not in favor of a change that removes the compensation 100%
>> from R3.14, and would postpone that change to R3.15.
>>
>> What do you think? I am happy to implement whatever the community
>> consensus is.
>>
>> Jeff
>>
- Replies:
- Re: timer delay compensation Benjamin Franksen
- Re: timer delay compensation Eric Norum
- Re: timer delay compensation Andrew Johnson
- Re: timer delay compensation Andrew Johnson
- References:
- timer delay compensation Hill, Jeff
- Re: timer delay compensation Eric Norum
- Navigate by Date:
- Prev:
Re: timer delay compensation Eric Norum
- Next:
Re: timer delay compensation Benjamin Franksen
- 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: timer delay compensation Eric Norum
- Next:
Re: timer delay compensation Benjamin Franksen
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
<2012>
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|