aboutsummaryrefslogtreecommitdiff
path: root/src/test/scheduler_tests.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Fix for Boost 1.74John-Gee2021-02-021-1/+1
|
* [Trivial] Grammar and typo correctionLauda2017-01-221-2/+2
| | | | Minor corrections in src\test\* .
* Increment MIT Licence copyright header year on files modified in 2016isle29832016-12-311-1/+1
| | | | | | Edited via: $ contrib/devtools/copyright_header.py update .
* Kill insecure_random and associated global stateWladimir J. van der Laan2016-10-171-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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`.
* Reenable multithread scheduler test.Pavel Janík2016-05-061-2/+0
|
* Bump copyright headers to 2015MarcoFalke2015-12-131-1/+1
|
* test: Disable scheduler test manythreadsWladimir J. van der Laan2015-12-011-0/+2
| | | | | | | It causes occasional deadlocks, resulting in false negatives in Travis. Disable the test for now. Works around #6540.
* More robust CScheduler unit testGavin Andresen2015-05-161-9/+18
| | | | | | | | | 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.
* CScheduler unit testGavin Andresen2015-05-141-0/+110