mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-09-22 22:14:58 +02:00
e106812a77
This should make our preferred solution to #6538 easier to implement, avoid a bunch of potential nastiness with excessive int-vs-double math, and generally make the code there a little less scary. "But wait!" you say. "Is it really safe to do this? Won't the results come out differently?" Yes, but not much. We now round every weighted bandwidth to the nearest byte before computing on it. This will make every node that had a fractional part of its weighted bandwidth before either slighty more likely or slightly less likely. Further, the rand_bw value was only ever set with integer precision, so it can't accurately sample routers with tiny fractional bandwidth values anyway. Finally, doing repeated double-vs-uint64 comparisons is just plain sad; it will involve an implicit cast to double, which is never a fun thing.
5 lines
228 B
Plaintext
5 lines
228 B
Plaintext
o Minor bugfixes:
|
|
- Switch weighted node selection rule from using a list of doubles
|
|
to using a list of int64_t. This should make the process slightly
|
|
easier to debug and maintain. Needed for fix for bug 6538.
|