[PATCH] posix: Fix relative CLOCK_REALTIME sleep

[Chris Johns]

On 1/8/2022 6:52 pm, Sebastian Huber wrote:
> On 01/08/2022 10:48, Chris Johns wrote:
>> On 1/8/2022 6:20 pm, Sebastian Huber wrote:
>>> On 01/08/2022 10:16, Chris Johns wrote:
>>>> On 1/8/2022 5:22 pm, Sebastian Huber wrote:
>>>>> A relative CLOCK_REALTIME time out shall not be affected by CLOCK_REALTIME
>>>>> changes through clock_settime().  Since our CLOCK_REALTIME is basically just
>>>>> CLOCK_MONOTONIC plus an offset, we can simply use the CLOCK_MONOTONIC watchdog
>>>>> for relative CLOCK_REALTIME time outs.
>>>> Thank for this. I can confirm it works with the modified test code I
>>>> attached to
>>>> the ticket. I am ts-validation-no-clock-0.exe now failing on
>>>> xilinx_zynq_a9_qemu
>>>> but I am not sure?
>>> I have to adjust the ts-validation-no-clock-0.exe if we want to fix the issue
>>> like this.
>>>
>>>> There is one issue my test changes have exposed and that is the ticks a thread
>>>> sleeps for is 1 more than the requested number.
>>> I think this is the expected behaviour. You should sleep at least the requested
>>> amount of time.
>> I am using 500msec so I would expect the result to be exact? If it was 501msec
>> then I would agree.
> 
> What do you mean with exact? If you want to wait for 500ms, then you will wake
> up in 500ms plus one clock tick interval (unless you measure the start time
> exactly at the clock tick event which is very unlikely).

Yeap I agree after looking at this again. You have to account for the extra tick.

Chris