Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D3D2D11DD for ; Wed, 30 Jan 2019 14:24:33 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi1-f180.google.com (mail-oi1-f180.google.com [209.85.167.180]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6A7A41FB for ; Wed, 30 Jan 2019 14:24:33 +0000 (UTC) Received: by mail-oi1-f180.google.com with SMTP id c206so19375952oib.0 for ; Wed, 30 Jan 2019 06:24:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lbry.io; s=google; h=mime-version:from:date:message-id:subject:to; bh=fkPi2Nj2XOw5OmUKaEpNb8bz/deR1QCI47XhxQ9MT4E=; b=CKxvOiSHF6uKMKZcfiQGCSIY8TOzNepzDoQkAn0BIc6wlHb4jteKFIkVgzIsIZKt+7 3o2aHaFBHxUBp/mUT9J3rpxfgyhXasO7HKVEx8KbHAlWjZcPfhC8bQQjw5aIXi7BEbYK VVwrG0eSvo+F7CFoJpDVRardYBgepy/MWZn2G2Kel46FTmjIUU/inhUWLJSUC6jdnhzi r+jtb8TzsZucPE4nsb8AXU9NiRRQFUhELRDEJtdCOL7w0op6iX2M7Y/zuGOKAnF4OVWK xAJCIF/WRRwQkwZlLdjIBsv/bCbiYc817Nd71KrkawFUmcL3Akh5tf+125Ovj6q7ksh8 Jqgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=fkPi2Nj2XOw5OmUKaEpNb8bz/deR1QCI47XhxQ9MT4E=; b=S9YW9jTRv2tUYwnzshhJQXp7QniZ++jeD42Xrffy+RUDjwrEpwwYTcdyFhlq5E9y3H eRgL2XwqWI/4tJGE6lW876urL+2KzaMiS/wEdrZzfr8vkCWysYZl8HDfzPqA2xwuBRYo gc8hVn0bcg1IdOVwgY9Kn+ZPHRGNNmS5fkmieZSwJgaGRNxytx3yPX2IM9igWWdDESGc 8F0ZFCXRtX9cBq9ed0RddgCslq8mlbVpdYnr75EeSX7AK4YpxpzKBgEJxCxx+/C/k+cg HLo96kMGOOFWbtLVZz7KAH8oa8PKgEi3v/Xa3DQSOpxijOEbQuF48oX40vYr/8N0zFRa RP5w== X-Gm-Message-State: AHQUAub8KGbwb85rTtlRQWmTYL5uQlcCO59rgvCtP+bChl2kUvWnWBo9 trW3IAXwSwRfn5dUe9q9+FTD4eZrZEB6IJbJJe4LFIBewxjbuA== X-Google-Smtp-Source: ALg8bN5aVahQV0M3D6AYq+PW6rNxkt9cCyFd2Gtz2dRvBrDGwlyB6o4n+h0XK9iyuWRFd3hhs+Rs4pdghcJ4MfWipvE= X-Received: by 2002:aca:c649:: with SMTP id w70mr12625660oif.186.1548858272461; Wed, 30 Jan 2019 06:24:32 -0800 (PST) MIME-Version: 1.0 From: Antoniy Shumanov Date: Wed, 30 Jan 2019 16:24:21 +0200 Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary="0000000000002348bb0580adab83" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Wed, 30 Jan 2019 14:52:42 +0000 Subject: [bitcoin-dev] Contribution X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2019 14:24:34 -0000 --0000000000002348bb0580adab83 Content-Type: text/plain; charset="UTF-8" Hi, bitcoin devs. I'm working at lbry.io and we stay closely to your core, i want to discuss what you think about a contribution like: base_blob and/or base_uint to be derived from std::array to be enabled move semantics, as well on uint160, uint256, COutPoint. Another approach that bother me is acquiring / releasing recursive mutex in a loop, snippet from minig.cpp while (nHeight < nHeightEnd && !ShutdownRequested()) { std::unique_ptr pblocktemplate(BlockAssembler(Params()).CreateNewBlock(coinbaseScript->reserveScript)); CBlock *pblock = &pblocktemplate->block; { LOCK(cs_main); // <--------- acquiring IncrementExtraNonce(pblock, chainActive.Tip(), nExtraNonce); } // <-------- release std::shared_ptr shared_pblock = std::make_shared(*pblock); if (!ProcessNewBlock(Params(), shared_pblock, true, nullptr)) // <---- acquiring / release again inside } Doing it in a loop makes things to be slow down even more, what's idea behind? Also consider using of atomic global variable rather than acquiring mutex again, no? Did you interested in contribution in these approaches? Regards Antoniy Shumanov --0000000000002348bb0580adab83 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, bitcoin devs. I'm working at= lbry.io and we stay closely to your core,
i want to discuss what you think about a contribution like:
<= div>base_blob and/or base_uint to be derived from std::array to be enabled = move
semantics, as well on uint160, uint256, COutPoint.
Another approach that bother me is acquiring / releasing recursive mutex i= n a loop, snippet from minig.cpp
while (nHeight < nHeightEnd &= amp;& !ShutdownRequested())
{
=C2=A0 =C2=A0 std::un= ique_ptr<CBlockTemplate>
=C2=A0 =C2=A0 pblocktemplate(Block= Assembler(Params()).CreateNewBlock(coinbaseScript->reserveScript));
<= /div>
=C2=A0 =C2=A0 CBlock *pblock =3D &pblocktemplate->block;
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 LOCK(cs_main= ); // <--------- acquiring
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Increme= ntExtraNonce(pblock, chainActive.Tip(), nExtraNonce);
=C2=A0 =C2= =A0 } // <-------- release
=C2=A0 =C2=A0 std::shared_ptr<co= nst CBlock> shared_pblock =3D
=C2=A0 =C2=A0 std::make_shared&l= t;const CBlock>(*pblock);
=C2=A0 =C2=A0 if (!ProcessNewBlock(P= arams(), shared_pblock, true, nullptr)) // <---- acquiring / release aga= in inside
}
Doing it in a loop makes things to be slow = down even more, what's idea behind?
Also consider using of at= omic global variable rather than acquiring mutex again, no?
Did y= ou interested in contribution in these approaches?

Regards
Antoniy Shumanov
--0000000000002348bb0580adab83--