Re: [BUG] queueing_enabled grows infinitely when in .recursive-edit

[Sebastian Gniazdowski <sgniazdowski@xxxxxxxxx>]

Or maybe this isn't problem at all. Any call not exactly at integer
SECONDS will be fixed to be near integer SECONDS as early as at second
scheduled call. Then, any possible drift away from integer SECONDS
will be always quickly fixed to integer SECONDS when diff == 0 is
checked at time(NULL) value change. So it's constant pull toward
integer SECONDS, nothing to worry about.


On 5 October 2016 at 07:56, Sebastian Gniazdowski
<sgniazdowski@xxxxxxxxx> wrote:
> On 3 October 2016 at 17:49, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
>> On Oct 3, 12:00pm, Sebastian Gniazdowski wrote:
>> }
>> } It looks like calc_timeout handles diff < 0 and diff > 0 but not diff
>> } == 0?
>>
>> Indeed, try this:
>>
> ...
>> -           if (diff < 0) {
>> +           if (diff <= 0) {
>
> It now appeared to me what the intention of diff < 0 could be. If one
> schedules at integer SECONDS + float 0.1, then after 100 ms time(NULL)
> will return different value and diff will be 0. So sched +1 scheduled
> function will run after 100ms. However next call will run as expected,
> near 1 second. I think this can be as it is, however maybe others
> would rather see ZTM_FUNC being returned for diff=0, so that select()
> still doesn't block, but sched +1 function will be ran when diff=-1.
> So, it's a matter of "scheduled function will run not earlier than
> scheduled time, up to 1 second late" vs. "scheduled function will run
> not later than scheduled time, up to 1 second early", both an effect
> of limited resolution of time(NULL).
>
> Best regards,
> Sebastian Gniazdowski