search

adinapoli / threads-supervisor

Simple, IO-based Haskell library for Erlang-inspired thread supervisors
MIT License
29 stars 4 forks source link

fix: make epochs monotonic #25

Closed srijs closed 8 years ago

srijs commented 8 years ago

There is a number of problems with using POSIX time for the epochs, the biggest one being that it is subject to leap seconds and other time adjustments, which might make time either "stand still" or even go backwards. The usual solution to this problem is to use what is called a monotonic clock. A monotonic clock does not provide an absolute point in time, but rather the time difference to a single local event (such as system start-up). By doing that, it can guarantee that time only ever progresses forward, and does so linearly.

This is quite an important property for the epochs, since a wrong time measurement could have us take into account expired dead letters, or possibly even worse, discard perfectly fine dead letters.

It does not quite solve everything, for example there is still a theoretical scenario where two dead letters happen within the same nanosecond, but it should improve things to the point where a failure is very unlikely.

The optimal solution would be to introduce a global counter that is incremented on every measurement of time (i.e. a logical, not a physical clock), to not only guarantee monotonicity, but in fact strict monotonicity, so that no two events could ever have the same epoch.

coveralls commented 8 years ago

Coverage Status

Coverage remained the same at 85.621% when pulling 66c8bcc0a34efbb832692ed5fa4daa80f14bc14c on fix/monotonic-epochs into ec44b0bb5a24f42d224396ec4513ecdf7d161fcb on master.

adinapoli commented 8 years ago

Hey @srijs , good catch, al always!

The optimal solution would be to introduce a global counter that is incremented on every measurement of time, to not only guarantee monotonicity, but in fact strict monotonicity, so that no two events could ever have the same epoch.

Agreed, and I like that solution more than this one, but I also think that might open different cans of worms (make sure we use things like IORefs, we use only atomic update operations, we do not have races on the counter etc) so I'll merge this one hoping we will never need such a fine grained control.

Thank you!