Use a polling mechanism instead of a look-forward loop

[sheerlox]

Refactor to poll and fire when condition is true.

Simplifies code a great deal and avoids all the issues which have repetitively been seen in attempts to determine the next running time.

This includes all the issues which were seen with using loops to look forward in time.

Originally posted by @mryellow in #962

[sheerlox]

@mryellow hmm. Yes, on one hand, that would simplify the code and prevent more issues with the loop mechanism in the future (this one is the last one "from the old days", so the mechanism should be pretty stable once it's fixed).

On the other hand, that would probably raise new types of issues we have never seen.

For example, what would happen if the event loop is blocked for a second when the polling mechanism would have triggered a tick? How could we detect that an execution has been missed in those cases to catch back?

The performance implications are also interesting. The polling mechanism would have to run every second (probably more frequently to mitigate the previous paragraph's issue), but since we'd only be checking for the current time it would be way less resource-intensive.

We'd also need a mechanism to prevent jobs from being run twice in a single second, which currently isn't an issue.

These are just the first observations that came to mind. A refactor this deep would have a lot of impacts we would have to take into consideration.

Given how widely used this library is in the ecosystem, we can't take this kind of refactoring lightly, and since we've almost fixed all bugs related to the look-forward logic, I don't think it would be a risk worth taking (nor time well spent).

But this is interesting nonetheless, I'm happy to entertain the discussion!

[mryellow]

should be pretty stable once it's fixed

Library has been playing wack-a-mole on this issue for years.

For example, what would happen if the event loop is blocked for a second when the polling mechanism would have triggered a tick? How could we detect that an execution has been missed in those cases to catch back?

By using a >= condition.

[sheerlox]

Library has been playing wack-a-mole on this issue for years.

If you look at the work we've been doing for a few years now, we've fixed every bug one by one, and the library's got in a very stable state.

#962 is the last major one (there are still a few other minor bugs), but we've been putting it off because we couldn't pinpoint it correctly (we actually could with enough effort, but couldn't find the time).

By using a >= condition.

Pretty sure that this simple solution isn't gonna cut it (because whatever direction you use it you'll just end up executing every second), but sure.

The point I'm trying to make is that this will be a huge piece of work, in terms of research, implementation, comprehensive testing, and debugging. We are maintaining this library in our free time, for free, out of passion and love for OSS software. We just don't have that kind of time, because the trade-offs aren't interesting enough.

But again, if you're willing to support the discussion with real arguments or even do some research/tests, this isn't a bad idea at all. Might not yield anything because of down-the-line discoveries, but definitely interesting to think about.