refactor: wrap accept() and extend usage of Sock #21879

pull vasild wants to merge 3 commits into bitcoin:master from vasild:SockAccept changing 7 files +93 −30
  1. vasild commented at 4:07 pm on May 7, 2021: member

    This is a piece of #21878, chopped off to ease review.

    Introduce an accept(2) wrapper Sock::Accept() and extend the usage of Sock in CConnman::ListenSocket and CreateNodeFromAcceptedSocket().

  2. DrahtBot added the label P2P on May 7, 2021
  3. DrahtBot added the label Utils/log/libs on May 7, 2021
  4. DrahtBot commented at 9:38 pm on May 7, 2021: member

    The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

    Conflicts

    Reviewers, this pull request conflicts with the following ones:

    • #23604 (Use Sock in CNode by vasild)
    • #23531 (Add Yggdrasil support by prusnak)
    • #21878 (Make all networking code mockable by vasild)

    If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

  5. practicalswift commented at 1:04 pm on May 8, 2021: contributor
    Concept ACK
  6. jonatack commented at 10:37 am on May 10, 2021: member
    Concept ACK
  7. DrahtBot added the label Needs rebase on May 19, 2021
  8. vasild force-pushed on May 19, 2021
  9. vasild commented at 11:53 am on May 19, 2021: member
    fb10bf2ba7...0f83150f14: rebase due to conflicts
  10. DrahtBot removed the label Needs rebase on May 19, 2021
  11. vasild force-pushed on May 20, 2021
  12. vasild commented at 1:35 pm on May 20, 2021: member
    0f83150f14...9f69aa45a8: rebase and follow the trend from #21659 and flag the newly added Sock::Accept() with [[nodiscard]]
  13. vasild force-pushed on Jun 3, 2021
  14. vasild commented at 2:39 pm on June 3, 2021: member
    9f69aa45a8...9f04449a8e: apply upstream changes.
  15. in src/test/util/net.h:140 in 11e59842e3 outdated
    116+            memset(addr, 0x00, *addr_len);
    117+            if (*addr_len >= sizeof(sockaddr_in)) {
    118+                *addr_len = sizeof(sockaddr_in);
    119+                sockaddr_in* addr_in = reinterpret_cast<sockaddr_in*>(addr);
    120+                addr_in->sin_family = AF_INET;
    121+                memset(&addr_in->sin_addr, 0x05, sizeof(addr_in->sin_addr));
    


    dhruv commented at 10:29 pm on June 7, 2021:
    (nit): Would inet_pton(AF_INET, "5.5.5.5", &addr_in->sin_addr); be clearer?

    vasild commented at 10:19 am on June 10, 2021:
    Yes, that would be clearer. However, some inet_...() function ended up using syscalls (it created sockets internally, IIRC) on Linux. @practicalswift, what do you think?
  16. in src/test/util/net.h:141 in 11e59842e3 outdated
    117+            if (*addr_len >= sizeof(sockaddr_in)) {
    118+                *addr_len = sizeof(sockaddr_in);
    119+                sockaddr_in* addr_in = reinterpret_cast<sockaddr_in*>(addr);
    120+                addr_in->sin_family = AF_INET;
    121+                memset(&addr_in->sin_addr, 0x05, sizeof(addr_in->sin_addr));
    122+                addr_in->sin_port = htons(6789);
    


    dhruv commented at 11:03 pm on June 7, 2021:
    Would it be useful for this address and port to be available as constants to use in tests?

    vasild commented at 10:22 am on June 10, 2021:
    They are not used anywhere else. Also, a legit code should expect an incoming connection to arrive from any address, so it would be bad to expose this, so that some code starts to depend on it or checks whether the accepted connection came from 5.5.5.5.
  17. dhruv commented at 8:19 pm on June 9, 2021: member

    crACK tACK 9f04449a8ec7dc167a0d6d0cb47c5facd205a81a

    Thank you for helping decouple our tests from system calls, @vasild. I also ran tests, and manually tested incoming connections on regtest using:

     0# Start node0 with -listen
     1$ src/bitcoind -regtest -datadir=`pwd`/node0 -rpccookiefile=.cookie -port=2222 -rpcport=3333 -listen
     2
     3# Generate a block on node0
     4$ src/bitcoin-cli -regtest -datadir=`pwd`/node0 -rpccookiefile=.cookie -rpcport=3333 createwallet test
     5$ src/bitcoin-cli -regtest -datadir=`pwd`/node0 -rpccookiefile=.cookie -rpcport=3333 -generate 
     6
     7# node0 has a block
     8$ src/bitcoin-cli -regtest -datadir=`pwd`/node0 -rpccookiefile=.cookie -rpcport=3333 getblockcount
     91
    10
    11$ src/bitcoin-cli -regtest -datadir=`pwd`/node0 -rpccookiefile=.cookie -rpcport=3333 getbestblockhash
    121878296b74ee617ff119d2fc3f85c9fb35eae952e0360e505bb7d325dfe9e825
    13
    14# Start node1
    15$ src/bitcoind -regtest -datadir=`pwd`/node1 -rpccookiefile=.cookie -port=2223 -rpcport=3334
    16
    17# node1 has no blocks
    18$ src/bitcoin-cli -regtest -datadir=`pwd`/node1 -rpccookiefile=.cookie -rpcport=3334 getblockcount
    190
    20
    21# Restart node1 with -addnode=node0
    22$ src/bitcoind -regtest -datadir=`pwd`/node1 -rpccookiefile=.cookie -port=2223 -rpcport=3334 -addnode=127.0.0.1:2222
    23
    24# node1 completes IBD and has the block
    25$ src/bitcoin-cli -regtest -datadir=`pwd`/node1 -rpccookiefile=.cookie -rpcport=3334 getblockcount
    261
    27
    28$ src/bitcoin-cli -regtest -datadir=`pwd`/node1 -rpccookiefile=.cookie -rpcport=3334 getbestblockhash
    291878296b74ee617ff119d2fc3f85c9fb35eae952e0360e505bb7d325dfe9e825
    

    Would the goal eventually be to not have to invoke Sock::Release() anywhere and instead use move semantics across the board as more code is RAII-fied?

  18. practicalswift commented at 9:24 am on June 10, 2021: contributor

    @vasild

    Very nice work.

    Non-blocking suggestion: Would it be possible to add a fuzzing harness utilizing FuzzedSock::Accept as part of this PR? It would be really nice to see this in action, and it would also transition FuzzedSock::Accept out of “unused code” territory :)

  19. vasild commented at 10:33 am on June 10, 2021: member

    Would the goal eventually be to not have to invoke Sock::Release() anywhere and instead use move semantics across the board as more code is RAII-fied?

    Yes! #21878 removes Sock::Release() in a later commit, called… eh… net: remove now unused Sock::Release() :smile:. It uses either move semantics or passes the Sock objects by reference if a function wants to use the socket but not claim ownership of it.

    Would it be possible to add a fuzzing harness utilizing FuzzedSock::Accept as part of this PR? …

    The Accept() method is only called from CConnman::AcceptConnection() which itself calls a bunch of other functions that are not mocked yet in this PR. All those are dealt with in #21878 which also adds fuzzing of CConnman::SocketHandler() (which calls CConnman::AcceptConnection()) in commit fuzz: add CConnman::SocketHandler() to the tests.

  20. jamesob approved
  21. jamesob commented at 9:42 pm on August 20, 2021: member

    ACK 9f04449a8ec7dc167a0d6d0cb47c5facd205a81a (jamesob/ackr/21879.1.vasild.wrap_accept_and_extend_u)

    Change looks good to me and, as others have noted, making network code more mockable will make writing more comprehensive tests feasible. Cloned locally and ran unit, functional tests.

    When I made the dumb mutation below, both test suites still passed so I guess we don’t have any tests exercising socket errors.

     0diff --git a/src/util/sock.cpp b/src/util/sock.cpp
     1index 9a92fd1b5f..e25c1bab7f 100644
     2--- a/src/util/sock.cpp
     3+++ b/src/util/sock.cpp
     4@@ -76,7 +76,7 @@ std::unique_ptr<Sock> Sock::Accept(sockaddr* addr, socklen_t* addr_len) const
     5 #ifdef WIN32
     6     static constexpr auto ERR = INVALID_SOCKET;
     7 #else
     8-    static constexpr auto ERR = SOCKET_ERROR;
     9+    static constexpr auto ERR = SOCKET_ERROR + 1;
    10 #endif
    11
    12     const auto socket = accept(m_socket, addr, addr_len);
    
     0-----BEGIN PGP SIGNED MESSAGE-----
     1Hash: SHA512
     2
     3ACK 9f04449a8ec7dc167a0d6d0cb47c5facd205a81a ([`jamesob/ackr/21879.1.vasild.wrap_accept_and_extend_u`](https://github.com/jamesob/bitcoin/tree/ackr/21879.1.vasild.wrap_accept_and_extend_u))
     4
     5Change looks good to me and, as others have noted, making network code more mockable will make writing comprehensive tests more feasible. Cloned locally and ran unit, functional tests.
     6
     7When I made the dumb mutation below, both test suites passed so I guess we don't have any tests exercising invalid socket errors.
     8
     9<patch>
    10-----BEGIN PGP SIGNATURE-----
    11
    12iQIzBAEBCgAdFiEEGNRVI1NPYuZCSIrGepNdrbLETwUFAmEgIVsACgkQepNdrbLE
    13TwWAvA/8C6OfGufmfaEdYzaaGVPyq1jmF7GmXsFo0T3AkflMBbMqri4Q+1ai1Yzs
    14CkVOuxGBDj8wiKxEeRsbsCsp3gbcOcp21ccvn6EQkPi0Mk8Rusj1iXgs+sDPuf7V
    15tKq3uQ54IbxkavKKWWhp5VeGrm4ddm8s2qF5uaN7UcGlGAPTw1915YW2HmEa3sC3
    169hQb+VGw3nkczUBJXMZls0AUF6E8XYTX3QycSGjlpazgSJac5J54trfvdCzpR1Ae
    170WlWndO/VROlePi6p2Mg0DHMCuuRyk78qCHx547WcaQxYWOic+XMEU1OELueLVbf
    18gf16So4iITHJWeK/GOLuecRfGm58uquWtQuzl5twzvPmzHRrwYyHrvgQP9eANzkQ
    19VCIbZWV7zL5ksgDGRJTwwzUERICvB6PqlzSU3a49f7kD2DnW+CMzHROe2YW+uLM7
    20lIn6fmw7WCLBAi990aOtlTf9eT4YYrkneNQYz4vnS/uWvNFBqrkCFxhTdBDHg0jr
    218EDzNVFtBFnxKBLYia+ybnPb8pqqAak2AYlrpYVSw6NWSlaWLq8d5JwqkNjgY2K1
    22anpssdubMvHmWk+N5e0rFbRg1froCMB3Fn7BhbSRbNlnKecv1M+WE1UgI8Y4Hlcn
    23nLxE/xMFHD94q9N79b76ENqDN8lOgTQmIbUVVcW+LKJpZ5bIQnU=
    24=EpEl
    25-----END PGP SIGNATURE-----
    
    0Tested on Linux-4.19.0-17-amd64-x86_64-with-glibc2.28
    1
    2Configured with ./configure LDFLAGS=-L/home/james/src/bitcoin/db4/lib/ CPPFLAGS=-I/home/james/src/bitcoin/db4/include/ CXXFLAGS=-fPIE -pipe -O2 -g -Wthread-safety-analysis -Wall -Werror=sign-compare --enable-wallet --with-daemon CXX=/usr/local/bin/clang++ CC=/usr/local/bin/clang --with-bignum=no PYTHONPATH= --disable-shared --with-pic --enable-benchmark=no --enable-module-recovery --enable-module-schnorrsig --enable-experimental --disable-shared --with-pic --enable-benchmark=no --enable-module-recovery --enable-module-schnorrsig --enable-experimental --no-create --no-recursion
    3
    4Compiled with /usr/bin/ccache /usr/local/bin/clang++ -std=c++17 -mavx -mavx2 -fPIE -pipe -O2 -g -Wthread-safety-analysis -Wall -Werror=sign-compare -fdebug-prefix-map=$(abs_srcdir)=.  -Wstack-protector -fstack-protector-all -fcf-protection=full -fstack-clash-protection -msse4 -msha -msse4.1 -msse4.2  i
    5
    6Compiler version: Debian clang version 11.1.0-++20210428103820+1fdec59bffc1-1~exp1~20210428204437.162
    
  22. vasild commented at 3:12 pm on August 23, 2021: member

    @jamesob, thanks for looking into this!

    Your mod changes ERR from -1 to 0 and the code looks like this:

    0    const auto socket = accept(m_socket, addr, addr_len);
    1    if (socket == 0) {
    2        return nullptr;
    3    }
    4    return std::make_unique<Sock>(socket);
    

    This will change the behavior in two cases:

    1. If accept() succeeds and returns socket=0. Could happen if stdin (fd=0) is closed and the descriptor number 0 is reused? In this case Sock::Accept() would return nullptr, signaling failure.
    2. If accept() fails and returns -1, then the check -1 == 0 would be false and Sock::Accept() would return a Sock object with internal m_socket equal to -1.

    I think it is unlikely that any of that happens (the real syscall accept() to return -1 or 0).

  23. jamesob commented at 10:53 pm on August 23, 2021: member
    @vasild yup, it was that second case I was curious about. Nothing wrong with this PR of course, just thought it might be interesting to note that we don’t seem to have any coverage for the accept()-fails branches. I think this PR will make it feasible to add such coverage, if that ends up being worth doing.
  24. vasild commented at 6:21 am on August 24, 2021: member
    Right! CConnman::AcceptConnection() is a candidate for fuzzing once all of #21878 is merged.
  25. vasild commented at 2:28 pm on August 27, 2021: member
    This PR has 2 ACKs and 2 Concept ACKs. @practicalswift, @jonatack, willing to upgrade your “Concept ACK"s to full code review ACKs?
  26. jonatack commented at 2:30 pm on August 27, 2021: member
    Yes, I was reviewing this a few days ago when I hit the addrman corruption issue from the asmap/addrman init order. Back to it soon!
  27. in src/util/sock.h:13 in 9f04449a8e outdated
     9@@ -10,6 +10,7 @@
    10 #include <util/time.h>
    11 
    12 #include <chrono>
    13+#include <memory>
    


    jonatack commented at 6:10 pm on September 22, 2021:
    11e59842e30ab5 nit if you retouch, add this header to the .cpp file as well

    vasild commented at 7:27 am on September 28, 2021:
    Added.
  28. jonatack approved
  29. jonatack commented at 6:33 pm on September 22, 2021: member

    Tested ACK 9f04449a8ec7dc167a0d6d0cb47c5facd205a81a rebased to master at a8a272ac32, code review, debug build and ran unit+functional tests at each commit, ran bitcoind on this branch head rebased to master on mainnet with a full range of connections including inbounds, behavior and debug log nominal

    This now has 3 ACKs by @dhruv, @jamesob and me.

  30. vasild force-pushed on Sep 28, 2021
  31. vasild commented at 7:27 am on September 28, 2021: member

    9f04449a8e...78e21e511e: rebase due to a silent windows-only “conflict” and address review suggestions.

    Invalidates ACKs from @dhruv, @jamesob, @jonatack.

  32. jonatack commented at 9:25 am on September 28, 2021: member
    Diff-review re-ACK 78e21e511ee241900b84d763462f26972d83b600 per git range-diff a9d0cec 9f04449 78e21e following my previous full review (https://github.com/bitcoin/bitcoin/pull/21879#pullrequestreview-761251278)
  33. vasild force-pushed on Sep 28, 2021
  34. vasild commented at 1:20 pm on September 28, 2021: member

    78e21e511e...07d998f05f: rebase to hopefully fix some unrelated CI failure.

    Invalidates ACK from @jonatack.

    ACKs on previous versions of this PR from @dhruv, @jamesob.

  35. MarcoFalke commented at 1:28 pm on September 28, 2021: member
    No need to invalidate ACKs for that. You can rerun the task yourself if it is a known issue (if not, report it first). If you don’t have the rights you can ask for it to be rerun.
  36. jonatack commented at 2:53 pm on September 28, 2021: member
    re-ACK 07d998f05f7cc9545324203240e2bbcaaab45b6a per git range-diff efa227f 78e21e5 07d998f
  37. DrahtBot added the label Needs rebase on Nov 8, 2021
  38. vasild force-pushed on Nov 10, 2021
  39. vasild commented at 10:36 am on November 10, 2021: member

    07d998f05f...0f4474d6da: rebase due to conflicts

    Invalidates ACK from @jonatack

    Previously invalidated ACKs from @dhruv, @jamesob

  40. DrahtBot removed the label Needs rebase on Nov 10, 2021
  41. jonatack commented at 6:40 pm on November 17, 2021: member
    re-ACK 0f4474d6da5741c7dc61cef403bb03faa2345f37 per git range-diff 2ef186a 07d998f 0f4474, re-review, rebase/debug build/ran units following my previous full review (https://github.com/bitcoin/bitcoin/pull/21879#pullrequestreview-761251278)
  42. DrahtBot added the label Needs rebase on Nov 24, 2021
  43. vasild force-pushed on Nov 26, 2021
  44. vasild commented at 11:04 am on November 26, 2021: member

    0f4474d6da...976f6e8bc9: rebase due to conflicts; close the accepted socket if std::make_unique() throws.

    Invalidates ACK from @jonatack

    Previously invalidated ACKs from @dhruv, @jamesob

  45. DrahtBot removed the label Needs rebase on Nov 26, 2021
  46. DrahtBot added the label Needs rebase on Dec 1, 2021
  47. net: add new method Sock::Accept() that wraps accept()
    This will help to increase `Sock` usage and make more code mockable.
    f8bd13f85a
  48. net: use Sock in CConnman::ListenSocket
    Change `CConnman::ListenSocket` to use a pointer to `Sock` instead of a
    bare `SOCKET` and use `Sock::Accept()` instead of bare `accept()`. This
    will help mocking / testing / fuzzing more code.
    9e3cbfca7c
  49. net: change CreateNodeFromAcceptedSocket() to take Sock
    Change `CConnman::CreateNodeFromAcceptedSocket()` to take a `Sock`
    argument instead of `SOCKET`.
    
    This makes the method mockable and also a little bit shorter as some
    `CloseSocket()` calls are removed (the socket will be closed
    automatically by the `Sock` destructor on early return).
    6bf6e9fd9d
  50. vasild force-pushed on Dec 1, 2021
  51. vasild commented at 3:37 pm on December 1, 2021: member

    976f6e8bc9...6bf6e9fd9d: rebase due to conflicts

    Previously invalidated ACKs from @jonatack, @dhruv, @jamesob

  52. DrahtBot removed the label Needs rebase on Dec 1, 2021
  53. jamesob approved
  54. jamesob commented at 8:37 pm on December 1, 2021: member

    ACK 6bf6e9fd9dece67878595a5f3361851c25833c49 (jamesob/ackr/21879.2.vasild.wrap_accept_and_extend_u)

    Examined interdiff and built/tested locally with a pre-populated datadir.

    Changes since last review include rebasing on master (CJDNS changes, vNodes -> m_nodes), some && sock function sig changes, write_len rephrasing, and catching exceptions during unique_ptr construction in Sock::Accept.

     0-----BEGIN PGP SIGNED MESSAGE-----
     1Hash: SHA512
     2
     3ACK 6bf6e9fd9dece67878595a5f3361851c25833c49 ([`jamesob/ackr/21879.2.vasild.wrap_accept_and_extend_u`](https://github.com/jamesob/bitcoin/tree/ackr/21879.2.vasild.wrap_accept_and_extend_u))
     4
     5Examined interdiff and built/tested locally with a pre-populated datadir.
     6
     7Changes since last review include rebasing on master (CJDNS changes, vNodes -> m_nodes), some
     8&& sock function sig changes, `write_len` rephrasing, and catching exceptions during unique_ptr
     9construction in Sock::Accept.
    10-----BEGIN PGP SIGNATURE-----
    11
    12iQIzBAEBCgAdFiEEGNRVI1NPYuZCSIrGepNdrbLETwUFAmGn3PIACgkQepNdrbLE
    13TwXzpw/+KLFtcxY3gB2hbfsjsm0IUUiY/FWnFL1S5ADu5HaFAMHHkT9cEfCsMhAn
    14oQeGgtKJ4+kp3j01JEHwo7Sa/XLj1CEKWLbLd3OFJyFgQ7GJr0X9Ej0RmHN67Rjz
    15B70DzBNe6FeRz/tST+fkVOULLJqj0bwg1FeVMsHK1bbAWCtl358O25flNeXy5zCI
    16tY5IAevJII5RP1YjbeTddY5VRPXBNP/dohEL6M5mvZdNsz5/OHz7VfuCbJtH1LBC
    17E7HcaMl8y70feJ4bVHuRmupx1+TYy5JUx1Aj05EcNzmkC/APHdTcL9bsZXiiOeHU
    18nvp81Ozq7oRe9ZkEzTPiKScPP6rqHbFILUE+dYW22P6qjDczHdge2sPVzcyIWKMR
    19CW7tG9PSo4dzRly+jh8T90ApnPe7oVQr6pzPVTjAlyuNHcS7CWYnEWS0Nha1zWyv
    20TYV2jC/53ugrqVnUAm+HbfTR2SIhTpYgYpUkYArHmEyXL/PZOnYB02+vgEhTsMkQ
    21JSYHb7AwlHoKr9R+S7XvkNG2TN2/2x4XZNTYr8sDvdNlxWLzsfTbTv1g9gfX/U1U
    22VFvJNFUaY/i8qq0FUKYgHvz0JMvaoRnsTx5w1K4m9tvdiNtA34TJy+y1sP1VPnnr
    237dA09N0rRu9BuAzioViAsd2eVZQS3TUOjvsYnKFL6EmsC/36lgg=
    24=HB8m
    25-----END PGP SIGNATURE-----
    
    0Tested on Linux-5.10.0-9-amd64-x86_64-with-glibc2.28
    1
    2Configured with ./configure LDFLAGS=-L/home/james/src/bitcoin/db4/lib/ CPPFLAGS=-I/home/james/src/bitcoin/db4/include/ CXXFLAGS=-fPIE -pipe -O2 -g -Wthread-safety-analysis -Wall -Werror=sign-compare -Wsign-compare -Werror=thread-safety-analysis --enable-wallet --enable-debug --with-daemon --enable-natpmp-default CXX=/usr/bin/clang++ CC=/usr/bin/clang PYTHONPATH= --disable-openssl-tests --disable-shared --with-pic --enable-benchmark=no --enable-module-recovery --enable-module-schnorrsig --enable-experimental --disable-shared --with-pic --enable-benchmark=no --enable-module-recovery --enable-module-schnorrsig --enable-experimental --disable-openssl-tests --no-create --no-recursion
    3
    4Compiled with /usr/bin/ccache /usr/bin/clang++ -std=c++17 -mavx -mavx2 -mpclmul -fPIE -pipe -O2 -g -Wthread-safety-analysis -Wall -Werror=sign-compare -Wsign-compare -Werror=thread-safety-analysis -O0 -g3 -ftrapv -fdebug-prefix-map=$(abs_top_srcdir)=.  -Wstack-protector -fstack-protector-all -fcf-protection=full -fstack-clash-protection -msse4 -msha -msse4.1 -msse4.2  i
    5
    6Compiler version: Debian clang version 13.0.1-++20211110052940+162f3f18c945-1~exp1~20211110053502.25
    
  55. jonatack approved
  56. jonatack commented at 1:13 pm on December 5, 2021: member
    ACK 6bf6e9fd9dece67878595a5f3361851c25833c49 per git range-diff ea989de 976f6e8 6bf6e9f – only change since my last review was s/listen_socket.socket/listen_socket.sock->Get()/ in src/net.cpp: CConnman::SocketHandlerListening() – re-read the code changes, rebase/debug build/ran units following my previous full review (https://github.com/bitcoin/bitcoin/pull/21879#pullrequestreview-761251278)
  57. jonatack commented at 9:12 pm on December 7, 2021: member
    Could maybe use another pair of eyes on this, but otherwise it seems RFM.
  58. MarcoFalke commented at 8:34 am on December 8, 2021: member
    It is unclear from the subject line and labels, but this is refactoring? It might be good to clarify that in the commit messages (if you need to push again) or at least in the pull request title and labels. This makes it easier for reviewers to see if it was accidental when it later turns out that this introduced any bugs or features.
  59. vasild renamed this:
    Wrap accept() and extend usage of Sock
    refactor: wrap accept() and extend usage of Sock
    on Dec 8, 2021
  60. vasild commented at 9:03 am on December 8, 2021: member
    Yes, this is refactor since it does not change external behavior. Updated the PR title. I can’t edit labels.
  61. MarcoFalke added the label Refactoring on Dec 8, 2021
  62. MarcoFalke removed the label Utils/log/libs on Dec 8, 2021
  63. w0xlt approved
  64. w0xlt commented at 11:55 pm on December 26, 2021: contributor

    tACK 6bf6e9f

    Ran the node on signet and the unit / functional tests.

    Seems good. Sock::Accept encapsulates the accept() system call, making the code more mockable and simpler due to the use of the RAII Sock class.

    If I understand correctly, instead of manually closing each socket from vhListenSocket, Sock destructor will automatically handle this after vhListenSocket.clear().

  65. vasild commented at 3:54 pm on January 4, 2022: member

    If I understand correctly, instead of manually closing each socket from vhListenSocket, Sock destructor will automatically handle this after vhListenSocket.clear().

    Yes!

  66. laanwj commented at 2:29 pm on January 5, 2022: member
    Code review ACK 6bf6e9fd9dece67878595a5f3361851c25833c49
  67. laanwj merged this on Jan 5, 2022
  68. laanwj closed this on Jan 5, 2022

  69. sidhujag referenced this in commit ce0854023e on Jan 6, 2022
  70. vasild deleted the branch on Jan 6, 2022
  71. DrahtBot locked this on Jan 6, 2023

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-11-17 12:12 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me