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 B3BF36BD23; Wed, 14 Apr 2021 13:00:34 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org B3BF36BD23 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1618394434; bh=YLB8fN1IFj7ahIQ9mdyfjX+k6i+nKlg9zDYdATXnHts=; h=Date:To:Cc:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=kWBqMRubYHyYjrxnFDZ59fvnA8FX4Tx8SNUcJ9Z2Iio+dvEQe7gCnXvv4Fjt72mPz PXWATnbUVEdvfLdE4dtCTa0kb/AfvJoL4MnJeTR0N0wwKT5x5Bg/qHdsLG80XUfhgu XvRlcx5dqOG6yKR3RWzepAsAODqgtFDeIwqKvwZI= Received: from mail-lf1-f45.google.com (mail-lf1-f45.google.com [209.85.167.45]) (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 3579C6BD23 for ; Wed, 14 Apr 2021 13:00:33 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 3579C6BD23 Received: by mail-lf1-f45.google.com with SMTP id r8so32076988lfp.10 for ; Wed, 14 Apr 2021 03:00:33 -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=8qEINsastYDsGC8fFzf/q35QOse2Y0Vvom6MDhZEm0A=; b=kfznUJnS5+4ARHLv4xZyu+a1RPesFvm8nJFmmevaLbK55s006ubW4D3Lt/9b9cMmKB XaBkMwF6bEDxF4Bayn2F2Ip5pjfpEGKr4wnv9cyQJKhC3ntx6T2QcmNE41nEi2+gxpDy swh2qubWPLbq9MyP+3gUCrf1KOZovSrAMBHiTfQA3a/ioCH0NBj4nwe/iT8lwJxijXeu uybcvXQay7vfhumsGKK63uBBxL2HY8/55bGw3xKxB4xjaXtIohX7e9qL64sTVUujY6Hm 2Ny5mq94unzylPs7wrLpmck9XWnA8/mEy+EY6BcxnOZlqruAe5lKaaEYbhK2KWPOqtRI oB3w== X-Gm-Message-State: AOAM532cre6C5CLlOfh2aw04VRcVkMtpHlLKN8jE/D8hGbmL2/4TfT91 VlEDqwZty9HqcG6WL1LU1kSWGAS4nWdL2g== X-Google-Smtp-Source: ABdhPJygKyb8WtDXIFxrCgEk898wFp4Yk05XWOpQTuQxqFmghAEj/LaYtaqwP2nOEPypDdwYNabxqw== X-Received: by 2002:ac2:58fc:: with SMTP id v28mr25014347lfo.201.1618394432011; Wed, 14 Apr 2021 03:00:32 -0700 (PDT) Received: from grain.localdomain ([5.18.199.94]) by smtp.gmail.com with ESMTPSA id g29sm4313240lfj.267.2021.04.14.03.00.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Apr 2021 03:00:31 -0700 (PDT) Received: by grain.localdomain (Postfix, from userid 1000) id 6132656014D; Wed, 14 Apr 2021 13:00:30 +0300 (MSK) Date: Wed, 14 Apr 2021 13:00:30 +0300 To: Serge Petrenko Cc: v.shpilevoy@tarantool.org, tarantool-patches@dev.tarantool.org Message-ID: References: <6641b0b1f98ff233ccb3a121833cb6363c45edcb.1618256019.git.sergepetrenko@tarantool.org> <77f903ff-2820-653c-e386-98e0704b189b@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <77f903ff-2820-653c-e386-98e0704b189b@tarantool.org> User-Agent: Mutt/2.0.5 (2021-01-21) Subject: Re: [Tarantool-patches] [PATCH v2 2/9] xrow: introduce a PROMOTE entry 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 Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" On Wed, Apr 14, 2021 at 12:12:51PM +0300, Serge Petrenko wrote: > > You know, while I understand that we're trying to reuse code flow > > here but I really don't like that this function unaware of type passed. > > IOW the function may easily overwire caller's stack if you occasionally > > pass synchro_body_bin instead of promote request. > > That's true and I've even caught that bug during the patch development. > > > > > Actually I've sevaral options: > > > > 1) make the caller to provide a size and use assert() inside > > this encoder to make sure the caller passer proper amount > > of data from stack; > > 2) provide own helper for promote packet encoding (see below). > > > > Still both approaches somehow *ugly* I think. Since there only a > > few use of this encodings it is easy to remember where and what > > and don't make a mistake. > > I think your second option looks better than what we have now. > So, thanks for the suggestion! I've taken your diff with a couple > of changes, please, take a look. > > The rest of the diff's in the reply for the 4th patch, because the > changes to txn_limbo.c belong there. Ack. Thanks!