[Tarantool-patches] [PATCH v4 1/3] gc/xlog: delay xlog cleanup until relays are subscribed

[Cyrill Gorcunov]

On Thu, Mar 25, 2021 at 08:59:53PM +0100, Vladislav Shpilevoy wrote:
> >  static double
> >  box_check_wal_cleanup_delay(void)
> >  {
> > +	const double MAX_TIMEOUT = TIMEOUT_INFINITY;
> > +	const double MIN_TIMEOUT = 0.001;
> 
> I am going to repeat it here from what I said verbally and
> in the chat - don't restrict the timeout. We never restrict
> any timeouts. TIMEOUT_INFINITY is not literally double inf
> value. It is just some huge but valid double value. User in
> his code can have a bigger definition of what is infinity.
> 
> The same with the min. Why do you limit it from below? I don't
> see a single reason for doing so. Only reasons against that -
> it is inconsistent with the other timeouts we have, and might
> conflict with how each particular user understand the "minimal"
> timeout.

Most important reason is an epsilon value on hw level, how many
users remember what exactly range the "machine zero" covers?
Do we really want to allow precision close to nanoseconds?
Surely it is not a problem to remove this limits from incoming
values, will do but actually this a bit bothers me.

> Instead, I asked you to check what if I pass Lua's math.huge
> value. AFAIK, it is not some finite double value, and it might
> break something.

LJLIB_PUSH(1e310) LJLIB_SET(huge)

If I remove the limits in arguments and call

	box.cfg{wal_cleanup_delay = math.huge}

then it passed into C level as 0x7fffffffffffffff
which is NaN in ieee-754.

2021-03-25 23:53:45.588 [2068763] main/103/interactive I> set 'wal_cleanup_delay' configuration option to inf

and cleanup fiber is sleeping forever because of comparition
specifics with NaN value.