Commit graph

9 commits

Author SHA1 Message Date
practicalswift
227ae9b34d [tests] Use FastRandomContext instead of boost::random::{mt19937,uniform_int_distribution} 2017-06-07 20:38:03 +02:00
Lauda
5c66d41b7f [Trivial] Grammar and typo correction
Minor corrections in src\test\* .
2017-01-22 13:18:51 +01:00
isle2983
27765b6403 Increment MIT Licence copyright header year on files modified in 2016
Edited via:

$ contrib/devtools/copyright_header.py update .
2016-12-31 11:01:21 -07:00
Wladimir J. van der Laan
5eaaa83ac1 Kill insecure_random and associated global state
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-10-17 13:08:35 +02:00
Pavel Janík
db18ab28c7 Reenable multithread scheduler test. 2016-05-06 20:44:39 +02:00
MarcoFalke
fa24439ff3 Bump copyright headers to 2015 2015-12-13 18:08:39 +01:00
Wladimir J. van der Laan
8f0d79e3c8 test: Disable scheduler test manythreads
It causes occasional deadlocks, resulting in false negatives in Travis.

Disable the test for now.
Works around #6540.
2015-12-01 14:43:38 +01:00
Gavin Andresen
f50105486f
More robust CScheduler unit test
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-16 17:59:23 -04:00
Gavin Andresen
68d370bec4
CScheduler unit test 2015-05-14 12:50:41 -04:00