Skip to content

Conversation

@ryanofsky
Copy link
Contributor

@ryanofsky ryanofsky commented Apr 22, 2020

This PR removes the g_rpc_node global, to get same benefits we see removing other globals and make RPC code more testable, modular, and reusable.

This uses a hybrid of the approaches suggested in #17548. Instead of using std::any, which isn't available in c++11, or void*, which isn't type safe, it uses a small new util::Ref helper class, which acts like a simplified std::any that only holds references, not values.

Motivation for writing this was to provide an simpler alternative to #18647 by Harris Brakmić (brakmic) which avoids some shortcomings of that PR (#18647 (comment))

@maflcko
Copy link
Member

maflcko commented Apr 22, 2020

Instead [...] void*, which isn't type safe, it uses a small new util::Ref

Why not NodeContext*? That might seem like a layer violation reading the source code, but practically it does the same and the diff would be smaller.

@ryanofsky
Copy link
Contributor Author

Instead [...] void*, which isn't type safe, it uses a small new util::Ref

Why not NodeContext*? That might seem like a layer violation reading the source code, but practically it does the same and the diff would be smaller.

This would allow only allow dropping the first commit. The later commits would look basically the same but with s/util::Ref/NodeContext/.

The practical reason I don't want to do this is I want to the be able to use the RPC server outside the node process. E.g. start a multiprocess wallet process and have it listen for wallet RPC requests. Maybe add more offline wallet support and be able to have wallet-tool respond to RPCs like listtransactions. In these cases, wallet code can't link against src/node/context.cpp and NodeContext is useless for passing wallet state (aside from just looking strange).

Also, RPC code in rpc/server and httprpc is mostly pretty generic and not bitcoin specific and personally I think it would be a shame to see bitcoin types leak into it.

@promag
Copy link
Contributor

promag commented Apr 22, 2020

From #18647 (comment)

Wallet RPC methods shouldn't have access to NodeContext. At some point we should have WalletContext struct that will hold things like vpwallets and let us get rid of wallet globals, and it would make sense for wallet RPC methods to have access to this. That is why suggestion from #17548 was to just add a new member to JSONRPCRequest that could hold a generic context, not something tied to the wallet or node. Other advantage of using JSONRPCRequest is that you dont' have to change RPC method signatures.

How would you implement this? Make context a map<string, any>? And do context["node"].Has<NodeContext>()?

@practicalswift
Copy link
Contributor

Concept ACK

Very happy to see g_rpc_node go!

Thanks for the great architectural work you are doing.

@ryanofsky
Copy link
Contributor Author

ryanofsky commented Apr 22, 2020

How would you implement this? Make context a map<string, any>? And do context["node"].Has<NodeContext>()?

No need for multiple contexts in the same request. interfaces::WalletClientImpl can just pass an different context to wallet RPC methods. Passing an interfaces::Chain reference would be sufficient enough for loadwallet / createwallet. But I actually want to introduce a WalletContext struct in src/wallet/context.h analagous to the NodeContext struct in src/node/context.h which would hold things like the Chain interface pointer and vpwallets vector.

@ryanofsky
Copy link
Contributor Author

Actually @promag, it is a little clumsier than I thought. I should change this PR to pass context to rpc method register calls instead of the StartHTTPRPC call to make this more future-proof (should still be an improvement as is)

@DrahtBot
Copy link
Contributor

DrahtBot commented Apr 22, 2020

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

Conflicts

Reviewers, this pull request conflicts with the following ones:

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.

Copy link
Contributor

@promag promag left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Concept ACK.

extern NodeContext* g_rpc_node;

CTxMemPool& EnsureMemPool();
NodeContext& EnsureNodeContext(const util::Ref& context);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have you considered EnsureNodeContext(const JSONRPCRequest& req) instead? Same for EnsureMemPool. Could avoid forward declaration above.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

re: #18740 (comment)

Have you considered EnsureNodeContext(const JSONRPCRequest& req) instead? Same for EnsureMemPool. Could avoid forward declaration above.

Probably considered it, but I don't like this style (along lines of c++ koan https://www.youtube.com/watch?v=Zx_Tjp9WIII&t=15m07s)

ryanofsky added a commit to ryanofsky/bitcoin that referenced this pull request Jun 1, 2020
Replace with RPC request reference to new WalletContext struct similar to the
existing NodeContext struct and reference.

This PR is a followup to 25ad2c6
bitcoin#18740 removing the g_rpc_node global.

Some later PRs will follow this up and move more wallet globals to the
WalletContext struct.

Co-authored-by: João Barbosa <[email protected]>
maflcko pushed a commit that referenced this pull request Jun 5, 2020
4a7253a Remove g_rpc_chain global (Russell Yanofsky)
e783197 refactor: replace RegisterWalletRPCCommands with GetWalletRPCCommands (Russell Yanofsky)

Pull request description:

  Replace with RPC request reference to new WalletContext struct similar to the existing NodeContext struct and reference.

  This PR is a followup to #18740 removing the g_rpc_node global.

  Some later PRs will follow this up and move more wallet globals to the WalletContext struct.

ACKs for top commit:
  MarcoFalke:
    ACK 4a7253a 🎋
  ariard:
    Code Review ACK 4a7253a, feel free to ignore comment it's super nit.

Tree-SHA512: 5bb5561c89f81811ca5232a58bf450e230d4218e62471c03227d142395fd36131672e99cb88329b33b9680a235db01e8b9d1c1e2a18288349e57205528deabab
sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Jun 5, 2020
4a7253a Remove g_rpc_chain global (Russell Yanofsky)
e783197 refactor: replace RegisterWalletRPCCommands with GetWalletRPCCommands (Russell Yanofsky)

Pull request description:

  Replace with RPC request reference to new WalletContext struct similar to the existing NodeContext struct and reference.

  This PR is a followup to bitcoin#18740 removing the g_rpc_node global.

  Some later PRs will follow this up and move more wallet globals to the WalletContext struct.

ACKs for top commit:
  MarcoFalke:
    ACK 4a7253a 🎋
  ariard:
    Code Review ACK 4a7253a, feel free to ignore comment it's super nit.

Tree-SHA512: 5bb5561c89f81811ca5232a58bf450e230d4218e62471c03227d142395fd36131672e99cb88329b33b9680a235db01e8b9d1c1e2a18288349e57205528deabab
deadalnix pushed a commit to Bitcoin-ABC/bitcoin-abc that referenced this pull request Oct 20, 2020
Summary:
This commit does not change behavior

Partial backport of core [[bitcoin/bitcoin#18740 | PR18740]]:
bitcoin/bitcoin@691c817

Test Plan:
  ninja check

Reviewers: #bitcoin_abc, jasonbcox

Reviewed By: #bitcoin_abc, jasonbcox

Differential Revision: https://reviews.bitcoinabc.org/D7989
jasonbcox pushed a commit to Bitcoin-ABC/bitcoin-abc that referenced this pull request Oct 20, 2020
Summary:
```
This commit does not change behavior
```

Partial backport of core [[bitcoin/bitcoin#18740 | PR18740]]:
bitcoin/bitcoin@6fca33b#diff-2ae094f9329ce9498e1b4a9cb7767945b54a33b4ee9fed4f0ba401a98e1683c1

Depends on D7988 and D7989.

Test Plan:
  ninja all check-all

Reviewers: #bitcoin_abc, jasonbcox, deadalnix

Reviewed By: #bitcoin_abc, jasonbcox, deadalnix

Subscribers: jasonbcox

Differential Revision: https://reviews.bitcoinabc.org/D7990
jasonbcox pushed a commit to Bitcoin-ABC/bitcoin-abc that referenced this pull request Oct 20, 2020
Summary:
```
This commit does not change behavior

-BEGIN VERIFY SCRIPT-
git grep -l g_rpc_node | xargs sed -i 's/g_rpc_node->/node./g'
-END VERIFY SCRIPT-
```

Partial backport of core [[bitcoin/bitcoin#18740 | PR18740]]:
bitcoin/bitcoin@ccb5059

Depends on D7990.

Test Plan:
  ninja all check-all

Reviewers: #bitcoin_abc, deadalnix

Reviewed By: #bitcoin_abc, deadalnix

Differential Revision: https://reviews.bitcoinabc.org/D7991
deadalnix pushed a commit to Bitcoin-ABC/bitcoin-abc that referenced this pull request Oct 20, 2020
Summary:
```
This commit does not change behavior
```

Concludes backport of core [[bitcoin/bitcoin#18740 | PR18740]]:
bitcoin/bitcoin@b3f7f37

Depends on D7991.

Test Plan:
  ninja all check-all

Reviewers: #bitcoin_abc, deadalnix

Reviewed By: #bitcoin_abc, deadalnix

Differential Revision: https://reviews.bitcoinabc.org/D7992
janus pushed a commit to janus/bitgesell that referenced this pull request Nov 15, 2020
Replace with RPC request reference to new WalletContext struct similar to the
existing NodeContext struct and reference.

This PR is a followup to 25ad2c623af30056ffb36dcd203a52edda2b170f
bitcoin/bitcoin#18740 removing the g_rpc_node global.

Some later PRs will follow this up and move more wallet globals to the
WalletContext struct.

Co-authored-by: João Barbosa <[email protected]>
@hebasto
Copy link
Member

hebasto commented Mar 28, 2021

@ryanofsky

This uses a hybrid of the approaches suggested in #17548. Instead of using std::any, which isn't available in c++11, or void*, which isn't type safe, it uses a small new util::Ref helper class, which acts like a simplified std::any that only holds references, not values.

The std::any requires that a type of a contained object must be CopyConstructible.
But std::is_copy_constructible<NodeContext>::value == false.

So, even with C++17, there are no simple ways to drop util::Ref in favor of std::any, unfortunately.

Or did I miss something?

@fanquake
Copy link
Member

So, even with C++17, there are no simple ways to drop util::Ref in favor of std::any, unfortunately.

It's being dropped for std::any in #21366.

PastaPastaPasta pushed a commit to PastaPastaPasta/dash that referenced this pull request Jul 1, 2021
…h_by_height

fcb7261 Prevent valgrind false positive in rest_blockhash_by_height (Russell Yanofsky)

Pull request description:

  A bad interaction between valgrind and clang 6.0.0-1ubuntu2 with -O2 optimizations makes valgrind misleadingly imply C++ code is reading an uninitialized blockheight value in `rest_blockhash_by_height` just because that's what clang optimized code is doing. The C++ code looks like:

  ```c++
  int32_t blockheight;
  if (!ParseInt32(height_str, &blockheight) || blockheight < 0) {
  ```

  while the optimized code looks like:

  ```
  0x00000000000f97ab <+123>:   callq  0x4f8860 <ParseInt32(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int*)>
  0x00000000000f97b0 <+128>:   mov    0xc(%rsp),%ebx
  0x00000000000f97b4 <+132>:   test   %ebx,%ebx
  0x00000000000f97b6 <+134>:   js     0xf98aa <rest_blockhash_by_height(util::Ref const&, HTTPRequest*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)+378>
  0x00000000000f97bc <+140>:   xor    $0x1,%al
  0x00000000000f97be <+142>:   jne    0xf98aa <rest_blockhash_by_height(util::Ref const&, HTTPRequest*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)+378>
  ```

  During the rest_interface.py test:

  https://github.com/bitcoin/bitcoin/blob/eef90c14ed0f559e3f6e187341009270b84f45cb/test/functional/interface_rest.py#L266

  when `height_str` is empty, `ParseInt32` returns false and `blockheight` value is never assigned. The optimized code reads the uninitialized `blockheight` value in `0xc(%rsp)` before the checking the `ParseInt32` return value in `%al`, which is harmless, but triggers the following error from valgrind:

  ```
  ==30660== Thread 13 b-httpworker.2:
  ==30660== Conditional jump or move depends on uninitialised value(s)
  ==30660==    at 0x2017B6: rest_blockhash_by_height(util::Ref const&, HTTPRequest*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (rest.cpp:614)
  ==30660==    by 0x2041B9: operator() (rest.cpp:670)
  ==30660==    by 0x2041B9: std::_Function_handler<bool (HTTPRequest*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&), StartREST(util::Ref const&)::$_1>::_M_invoke(std::_Any_data const&, HTTPRequest*&&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (std_function.h:301)
  ==30660==    by 0x3EC994: operator() (std_function.h:706)
  ==30660==    by 0x3EC994: HTTPWorkItem::operator()() (httpserver.cpp:55)
  ==30660==    by 0x3ED16D: WorkQueue<HTTPClosure>::Run() (httpserver.cpp:114)
  ==30660==    by 0x3E9168: HTTPWorkQueueRun(WorkQueue<HTTPClosure>*, int) (httpserver.cpp:342)
  ==30660==    by 0x3EDAAA: __invoke_impl<void, void (*)(WorkQueue<HTTPClosure> *, int), WorkQueue<HTTPClosure> *, int> (invoke.h:60)
  ==30660==    by 0x3EDAAA: __invoke<void (*)(WorkQueue<HTTPClosure> *, int), WorkQueue<HTTPClosure> *, int> (invoke.h:95)
  ==30660==    by 0x3EDAAA: _M_invoke<0, 1, 2> (thread:234)
  ==30660==    by 0x3EDAAA: operator() (thread:243)
  ==30660==    by 0x3EDAAA: std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (*)(WorkQueue<HTTPClosure>*, int), WorkQueue<HTTPClosure>*, int> > >::_M_run() (thread:186)
  ==30660==    by 0x64256DE: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.25)
  ==30660==    by 0x54876DA: start_thread (pthread_create.c:463)
  ==30660==    by 0x6DC888E: clone (clone.S:95)
  ==30660==  Uninitialised value was created by a stack allocation
  ==30660==    at 0x20173A: rest_blockhash_by_height(util::Ref const&, HTTPRequest*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (rest.cpp:608)
  ==30660==
  {
     <insert_a_suppression_name_here>
     Memcheck:Cond
     fun:_ZL24rest_blockhash_by_heightRKN4util3RefEP11HTTPRequestRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
     fun:operator()
     fun:_ZNSt17_Function_handlerIFbP11HTTPRequestRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEZ9StartRESTRKN4util3RefEE3$_1E9_M_invokeERKSt9_Any_dataOS1_S9_
     fun:operator()
     fun:_ZN12HTTPWorkItemclEv
     fun:_ZN9WorkQueueI11HTTPClosureE3RunEv
     fun:_ZL16HTTPWorkQueueRunP9WorkQueueI11HTTPClosureEi
     fun:__invoke_impl<void, void (*)(WorkQueue<HTTPClosure> *, int), WorkQueue<HTTPClosure> *, int>
     fun:__invoke<void (*)(WorkQueue<HTTPClosure> *, int), WorkQueue<HTTPClosure> *, int>
     fun:_M_invoke<0, 1, 2>
     fun:operator()
     fun:_ZNSt6thread11_State_implINS_8_InvokerISt5tupleIJPFvP9WorkQueueI11HTTPClosureEiES6_iEEEEE6_M_runEv
     obj:/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.25
     fun:start_thread
     fun:clone
  }
  ```

  This is a known bad interaction between clang and valgrind. The clang optimized code is correct but valgrind has no way of knowing that accessing the uninitialized value isn't a problem. Issue has been reported previously:

  - https://bugs.llvm.org/show_bug.cgi?id=32604#c4
  - Z3Prover/z3#972

  This commit just sets blockheight to -1 as a workaround.

  This change was originally made in 41d5d65 from bitcoin#18740 to fix the travis error there (https://travis-ci.org/github/bitcoin/bitcoin/jobs/678453061#L7157) but MarcoFalke suggested bitcoin#18740 (comment) moving to a new PR, since apparently the error's been seen on travis previously

ACKs for top commit:
  MarcoFalke:
    ACK fcb7261
  practicalswift:
    ACK fcb7261

Tree-SHA512: ec8abf45bd3d6c6e0e7e404d0b2a749efd43910619b84b0b5fe7dab22881598d1011a0f3ff2e146bf46320b63eb152bf63c62c06f1ab84c35dd640abc468f18f
PastaPastaPasta pushed a commit to PastaPastaPasta/dash that referenced this pull request Jul 14, 2021
…h_by_height

fcb7261 Prevent valgrind false positive in rest_blockhash_by_height (Russell Yanofsky)

Pull request description:

  A bad interaction between valgrind and clang 6.0.0-1ubuntu2 with -O2 optimizations makes valgrind misleadingly imply C++ code is reading an uninitialized blockheight value in `rest_blockhash_by_height` just because that's what clang optimized code is doing. The C++ code looks like:

  ```c++
  int32_t blockheight;
  if (!ParseInt32(height_str, &blockheight) || blockheight < 0) {
  ```

  while the optimized code looks like:

  ```
  0x00000000000f97ab <+123>:   callq  0x4f8860 <ParseInt32(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int*)>
  0x00000000000f97b0 <+128>:   mov    0xc(%rsp),%ebx
  0x00000000000f97b4 <+132>:   test   %ebx,%ebx
  0x00000000000f97b6 <+134>:   js     0xf98aa <rest_blockhash_by_height(util::Ref const&, HTTPRequest*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)+378>
  0x00000000000f97bc <+140>:   xor    $0x1,%al
  0x00000000000f97be <+142>:   jne    0xf98aa <rest_blockhash_by_height(util::Ref const&, HTTPRequest*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)+378>
  ```

  During the rest_interface.py test:

  https://github.com/bitcoin/bitcoin/blob/eef90c14ed0f559e3f6e187341009270b84f45cb/test/functional/interface_rest.py#L266

  when `height_str` is empty, `ParseInt32` returns false and `blockheight` value is never assigned. The optimized code reads the uninitialized `blockheight` value in `0xc(%rsp)` before the checking the `ParseInt32` return value in `%al`, which is harmless, but triggers the following error from valgrind:

  ```
  ==30660== Thread 13 b-httpworker.2:
  ==30660== Conditional jump or move depends on uninitialised value(s)
  ==30660==    at 0x2017B6: rest_blockhash_by_height(util::Ref const&, HTTPRequest*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (rest.cpp:614)
  ==30660==    by 0x2041B9: operator() (rest.cpp:670)
  ==30660==    by 0x2041B9: std::_Function_handler<bool (HTTPRequest*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&), StartREST(util::Ref const&)::$_1>::_M_invoke(std::_Any_data const&, HTTPRequest*&&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (std_function.h:301)
  ==30660==    by 0x3EC994: operator() (std_function.h:706)
  ==30660==    by 0x3EC994: HTTPWorkItem::operator()() (httpserver.cpp:55)
  ==30660==    by 0x3ED16D: WorkQueue<HTTPClosure>::Run() (httpserver.cpp:114)
  ==30660==    by 0x3E9168: HTTPWorkQueueRun(WorkQueue<HTTPClosure>*, int) (httpserver.cpp:342)
  ==30660==    by 0x3EDAAA: __invoke_impl<void, void (*)(WorkQueue<HTTPClosure> *, int), WorkQueue<HTTPClosure> *, int> (invoke.h:60)
  ==30660==    by 0x3EDAAA: __invoke<void (*)(WorkQueue<HTTPClosure> *, int), WorkQueue<HTTPClosure> *, int> (invoke.h:95)
  ==30660==    by 0x3EDAAA: _M_invoke<0, 1, 2> (thread:234)
  ==30660==    by 0x3EDAAA: operator() (thread:243)
  ==30660==    by 0x3EDAAA: std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (*)(WorkQueue<HTTPClosure>*, int), WorkQueue<HTTPClosure>*, int> > >::_M_run() (thread:186)
  ==30660==    by 0x64256DE: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.25)
  ==30660==    by 0x54876DA: start_thread (pthread_create.c:463)
  ==30660==    by 0x6DC888E: clone (clone.S:95)
  ==30660==  Uninitialised value was created by a stack allocation
  ==30660==    at 0x20173A: rest_blockhash_by_height(util::Ref const&, HTTPRequest*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (rest.cpp:608)
  ==30660==
  {
     <insert_a_suppression_name_here>
     Memcheck:Cond
     fun:_ZL24rest_blockhash_by_heightRKN4util3RefEP11HTTPRequestRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
     fun:operator()
     fun:_ZNSt17_Function_handlerIFbP11HTTPRequestRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEZ9StartRESTRKN4util3RefEE3$_1E9_M_invokeERKSt9_Any_dataOS1_S9_
     fun:operator()
     fun:_ZN12HTTPWorkItemclEv
     fun:_ZN9WorkQueueI11HTTPClosureE3RunEv
     fun:_ZL16HTTPWorkQueueRunP9WorkQueueI11HTTPClosureEi
     fun:__invoke_impl<void, void (*)(WorkQueue<HTTPClosure> *, int), WorkQueue<HTTPClosure> *, int>
     fun:__invoke<void (*)(WorkQueue<HTTPClosure> *, int), WorkQueue<HTTPClosure> *, int>
     fun:_M_invoke<0, 1, 2>
     fun:operator()
     fun:_ZNSt6thread11_State_implINS_8_InvokerISt5tupleIJPFvP9WorkQueueI11HTTPClosureEiES6_iEEEEE6_M_runEv
     obj:/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.25
     fun:start_thread
     fun:clone
  }
  ```

  This is a known bad interaction between clang and valgrind. The clang optimized code is correct but valgrind has no way of knowing that accessing the uninitialized value isn't a problem. Issue has been reported previously:

  - https://bugs.llvm.org/show_bug.cgi?id=32604#c4
  - Z3Prover/z3#972

  This commit just sets blockheight to -1 as a workaround.

  This change was originally made in 41d5d65 from bitcoin#18740 to fix the travis error there (https://travis-ci.org/github/bitcoin/bitcoin/jobs/678453061#L7157) but MarcoFalke suggested bitcoin#18740 (comment) moving to a new PR, since apparently the error's been seen on travis previously

ACKs for top commit:
  MarcoFalke:
    ACK fcb7261
  practicalswift:
    ACK fcb7261

Tree-SHA512: ec8abf45bd3d6c6e0e7e404d0b2a749efd43910619b84b0b5fe7dab22881598d1011a0f3ff2e146bf46320b63eb152bf63c62c06f1ab84c35dd640abc468f18f
kwvg added a commit to kwvg/dash that referenced this pull request May 18, 2022
malbit added a commit to malbit/raptoreum that referenced this pull request Aug 7, 2022
[bitcoin#14624](bitcoin/bitcoin#14624)
bls refactoring to resolve clang warnings
[bitcoin#16426](bitcoin/bitcoin#16426) - cs_wallet lock order refactoring and reduce cs_main locking
atomic smartnode_connection (allow read/write by different threads simultaneously)
cs_mnauth locks on verifiedProRegTxHash read
RecursiveMutex at locking access to activeSmartNode
[bitcoin#14307](bitcoin/bitcoin#14307) - Consolidate redundant implementation of ParseHashStr
[bitcoin#13399](bitcoin/bitcoin#13399) - rpc: Add submitheader
built-in miner deleted
[bitcoin#17781](bitcoin/bitcoin#17781) - Remove mempool global from miner
[bitcoin#16623](bitcoin/bitcoin#16624) - encapsulate transactions state
[bitcoin#15931](bitcoin/bitcoin#15931) - Remove GetDepthInMainChain dependency on locked chain interface
Pass CConnman to function against global pointer
[bitcoin#16839](bitcoin/bitcoin#16839) - Replace Connman and BanMan globals with NodeContext local
[bitcoin#16034](bitcoin/bitcoin#16034) - refactoring: Rename LockAnnotation to LockAssertion and add run-time check to it
[bitcoin#17564](bitcoin/bitcoin#17564) - Use mempool from node context instead of global
[bitcoin#18740](bitcoin/bitcoin#18740) - Remove g_rpc_node global
[bitcoin#19096](bitcoin/bitcoin#19096) - Remove g_rpc_chain global
[bitcoin#18338](bitcoin/bitcoin#18338) - Fix wallet unload race condition
other fixes and tweaks
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Aug 16, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants