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_R
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_R
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
>>> CL
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 CLOC
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 CLO
