Much runtime under cs_main seemed unneeded here.
cs_main is a highly contended lock that is held for a long time.
Let's not merge without careful review & testing...
Much runtime under cs_main seemed unneeded here.
cs_main is a highly contended lock that is held for a long time.
Let's not merge without careful review & testing...
Much runtime under cs_main seemed unneeded here.
There are a couple static variables, but that does not require cs_main.
Automatic sanity-testing: FAILED BUILD/TEST, see http://jenkins.bluematt.me/pull-tester/p4795_0731a8dbf41b781bb1287c453ec4d711a7dcdd54/ for binaries and test log.
This could happen for one of several reasons:
If you believe this to be in error, please ping BlueMatt on freenode or TheBlueMatt here.
This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.
4248 | @@ -4249,13 +4249,39 @@ bool SendMessages(CNode* pto, bool fSendTrickle) 4249 | } 4250 | } 4251 | 4252 | - TRY_LOCK(cs_main, lockMain); // Acquire cs_main for IsInitialBlockDownload() and CNodeState() 4253 | - if (!lockMain) 4254 | - return true; 4255 | + bool isIBD; 4256 | + CNodeState state;
Making a copy of state sounds dangerous, as there is global state that contains iterators to entries in it.
Decreasing the time cs_main is locked (or even splitting it up further), but the largest offender by far is ProcessBlock. Trying to run SendMessages without cs_main sounds like asking for trouble, though.