Avoid locking cs_main in the folllowing wallet RPC:
decoderawtransactiongetnewaddressgetrawchangeaddresssetlabel
Avoid locking cs_main in the folllowing wallet RPC:
decoderawtransactiongetnewaddressgetrawchangeaddresssetlabelCan you please add some rationale as to how you checked that the cs_main lock can be safely removed from these functions?
I've manually checked what calls were made in each RPC, and checked that none uses something protected by cs_main. I guess this could be checked by AssertLockIsHeld or similar, but it's not widely adopted yet.
Thanks. What I'm a little bit worried about is that some of the CWallet calls might internally lock cs_main, which will cause potential deadlocks due to lock ordering if cs_wallet is already held. Or maybe not now, but that someone will do so in the future.
This +6/-7 change should go into a single commit
@MarcoFalke Squashed 909cad7...eb29e2536. Updated PR description.
Needs rebase due to travis bug
Thanks @MarcoFalke, rebased.
utACK ca7a86acbc3bd0c9f24962e41b9aed36a7a229f4
utACK ca7a86a. Agree that lock-order inversion is caught by travis or review.
Rebased.
re-utACK 8c00f6569fb1f69c63a62025f07f7f821ed63064
re-utACK 00f58f8c48db05dce9dceed73a0028482e037f0f
utACK 00f58f8c48db05dce9dceed73a0028482e037f0f