aboutsummaryrefslogtreecommitdiff
path: root/src/test/scheduler_tests.cpp
AgeCommit message (Collapse)Author
2017-06-07[tests] Use FastRandomContext instead of ↵practicalswift
boost::random::{mt19937,uniform_int_distribution}
2017-01-22[Trivial] Grammar and typo correctionLauda
Minor corrections in src\test\* .
2016-12-31Increment MIT Licence copyright header year on files modified in 2016isle2983
Edited via: $ contrib/devtools/copyright_header.py update .
2016-10-17Kill insecure_random and associated global stateWladimir J. van der Laan
There are only a few uses of `insecure_random` outside the tests. This PR replaces uses of insecure_random (and its accompanying global state) in the core code with an FastRandomContext that is automatically seeded on creation. This is meant to be used for inner loops. The FastRandomContext can be in the outer scope, or the class itself, then rand32() is used inside the loop. Useful e.g. for pushing addresses in CNode or the fee rounding, or randomization for coin selection. As a context is created per purpose, thus it gets rid of cross-thread unprotected shared usage of a single set of globals, this should also get rid of the potential race conditions. - I'd say TxMempool::check is not called enough to warrant using a special fast random context, this is switched to GetRand() (open for discussion...) - The use of `insecure_rand` in ConnectThroughProxy has been replaced by an atomic integer counter. The only goal here is to have a different credentials pair for each connection to go on a different Tor circuit, it does not need to be random nor unpredictable. - To avoid having a FastRandomContext on every CNode, the context is passed into PushAddress as appropriate. There remains an insecure_random for test usage in `test_random.h`.
2016-05-06Reenable multithread scheduler test.Pavel Janík
2015-12-13Bump copyright headers to 2015MarcoFalke
2015-12-01test: Disable scheduler test manythreadsWladimir J. van der Laan
It causes occasional deadlocks, resulting in false negatives in Travis. Disable the test for now. Works around #6540.
2015-05-16More robust CScheduler unit testGavin Andresen
On a busy or slow system, the CScheduler unit test could fail because it assumed all threads would be done after a couple of milliseconds. Replace the hard-coded sleep with CScheduler stop() method that will cleanly exit the servicing threads when all tasks are completely finished.
2015-05-14CScheduler unit testGavin Andresen