From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id 475C16F3C7; Fri, 26 Mar 2021 00:03:02 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 475C16F3C7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1616706182; bh=iDudfgHiTqoFDUDwSWFgScevOVnMhvRPE3JeMttl2AE=; h=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=Ht8d4tUCTQsdTyliyTNdHMpfXKDARndYZrkPrmdqvsw+0g9lTvigBO4emiGIjQLjZ HWlBqVAl2jS5gzBulw5tCwEZMUU7cICq625lGqc6bZDjP0ImXNlM5bsGMEaW1GPr3N DBPZB6BvC8sok6NUvmqVk+egkL6TETXBGBa9Uprg= Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com [209.85.208.180]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 6F3026F3C7 for ; Fri, 26 Mar 2021 00:03:00 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 6F3026F3C7 Received: by mail-lj1-f180.google.com with SMTP id 15so5008838ljj.0 for ; Thu, 25 Mar 2021 14:03:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=HigAoEsQ0Wcft71bFgj/yJ291nM/J+WFugL21saP4ws=; b=Q7xHQprLSQoAsrDkprwPzgQBVFdMzjUMPPF2P/EecBQFg5PXZzkQ2NjokDutfT8aE5 r7rf/gBqucxr19xoMc6qF1kyJMKkH44JIYMnuH8CpNiDv4L0lM/UVq1/rBTSk3c9zAH0 5+GI2nTEmskc/7yUS2xTW+HlLsXA7PvO7KnCT2jLJbB5CoVyY1QpW36zP/E/Y9zALF+w PCwYY3F67JrcAM1iLG7SY4H9W8xEu3lkqim6lMYiV7kV/NXY3I9VVezphbgsPzS93RNL oDvuyXDyMTuSZ0YqS0ciiFcyF2Up/Bk920UEOc+QkNVKe+FblR4vAXXhboDei6N8Pwat GsKw== X-Gm-Message-State: AOAM531uDV65Y/sDxNaNteqJtmgXiVZE5DlaEjmw4C6XgE7IezWLOZxq vuKy/8uJLVFCRq+wThLVCo95/CwSwp+7bw== X-Google-Smtp-Source: ABdhPJxa2WldTJ1SZYRp7kr3F2PecPrnA3h/rebGrRmV/BG62yaczf3SW/83/HyW0dGDntlhrGy4HQ== X-Received: by 2002:a2e:95d2:: with SMTP id y18mr7229608ljh.353.1616706178936; Thu, 25 Mar 2021 14:02:58 -0700 (PDT) Received: from grain.localdomain ([5.18.171.94]) by smtp.gmail.com with ESMTPSA id v8sm650265lfd.189.2021.03.25.14.02.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Mar 2021 14:02:57 -0700 (PDT) Received: by grain.localdomain (Postfix, from userid 1000) id 9D022560179; Fri, 26 Mar 2021 00:02:56 +0300 (MSK) Date: Fri, 26 Mar 2021 00:02:56 +0300 To: Vladislav Shpilevoy Message-ID: References: <20210324163759.1900553-1-gorcunov@gmail.com> <20210324163759.1900553-2-gorcunov@gmail.com> <8faa2e1e-c198-832d-d527-1acf2280720d@tarantool.org> <19605c5e-e96c-8580-6309-3b0e58df8c01@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19605c5e-e96c-8580-6309-3b0e58df8c01@tarantool.org> User-Agent: Mutt/2.0.5 (2021-01-21) Subject: Re: [Tarantool-patches] [PATCH v4 1/3] gc/xlog: delay xlog cleanup until relays are subscribed X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Cyrill Gorcunov via Tarantool-patches Reply-To: Cyrill Gorcunov Cc: tml Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" 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.