Skip Menu |

This queue is for tickets about the IO-Async CPAN distribution.

Report information
The Basics
Id: 122961
Status: new
Priority: 0/
Queue: IO-Async
People
Owner: Nobody in particular
Requestors: leonerd-cpan [...] leonerd.org.uk
Cc:
AdminCc:
Bug Information
Severity: (no value)
Broken in: 0.71
Fixed in: (no value)

History Show all quoted text
  Tue Sep 05 07:13:24 2017 leonerd-cpan [...] leonerd.org.uk - Ticket created
Subject: Better handling of the multiple clocks
Currently all of IO::Async's core is ignorant of the multiple clocks; namely the distinction between CLOCK_MONOTONIC and CLOCK_REALTIME. It blurs the distinction between the two, presuming them to always run exactly in step with each other. This generally doesn't cause too much trouble, except at those times when they diverge. E.g. when wallclock time is set by administrative action, or by ntpd. Already occasionally the effects can be seen if there is a small amount of clock rate skew between MONOTONIC (the basis that poll(2) and select(2) use) vs REALTIME (the basis that gettimeofday(2) uses), when sometimes a poll() wait for a calculated time doesn't observe the same amount of time passing according to gettimeofday(). To fix this, we'd need to take account of the clock basis when handling time-related matters. -- Paul Evans
  Tue Sep 05 07:17:02 2017 leonerd-cpan [...] leonerd.org.uk - Correspondence added
An initial attack at this problem could be solved by storing two TimerQueue objects, one for the each clock. When making a ->watch_time call the caller would have to specify which clock is being used (likely these would default to MONOTONIC for 'after' timers, or REALTIME for 'at' timers). A question comes in the form of how we calculate the maxwait time for the next poll() call, when both queues are non-empty. Or in fact in general, when the REALTIME queue contains an element. On platforms like Linux we have the timerfd(2) system call, which can give us a filehandle that's ready at some instant on some given clock, so we can use that to reliably wait for the exact epoch time on the REALTIME queue. Without that, I think the only viable strategy is to presume that the two clocks won't diverge too much in a short time, and bound the "short time" we'll allow between resynchronisations by clamping a maximum wait time, in a similar trick to the signal pipe hackery around https://metacpan.org/source/PEVANS/IO-Async-0.71/lib/IO/Async/Loop.pm#L45-53 -- Paul Evans