No need to hold cs_main when serializing a struct to json
Fixes: #15925
No need to hold cs_main when serializing a struct to json
Fixes: #15925
Does it make sense to add an AssertLockNotHeld(cs_main) to those functions?
For reference #12153 (comment).
Concept ACK.
Does it make sense to add an
AssertLockNotHeld(cs_main)to those functions?
Maybe EXCLUDES annotation instead?
Concept ACK. The whole point of moving the lock of cs_main inside the individual RPC functions was to allow optimizations such as this.
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--174a7506f384e20aa4161008e828411d-->
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.
utACK faea56400d5578023133cf4d1c761cdeb0c3e3da
Why not use ENTER_CRITICAL_SECTION & LEAVE_CRITICAL_SECTION instead LOCK?
Because a scoped lock is more clear and "secure".
utACK faea56400d5578023133cf4d1c761cdeb0c3e3da
11 | +#include <sync.h> 12 | + 13 | +#include <stdint.h> 14 | +#include <vector> 15 | + 16 | +extern RecursiveMutex cs_main;
@MarcoFalke Do you use RecursiveMutex instead of CCriticalSection on purpose?