Commit Graph

11 Commits

Author SHA1 Message Date
Nick Mathewson
2d69c32bb6 Clean up include paths for libtor-evloop (automated) 2018-07-05 15:22:17 -04:00
Nick Mathewson
52884f56d4 Replace U64_LITERAL with the standard UINT64_C 2018-07-03 10:33:50 -04:00
Nick Mathewson
0dab29ce10 Run rectify_include_paths.py 2018-06-20 09:35:05 -04:00
David Goulet
ae4e5b9824 token: Fix uint32_t to uint64_t conversion
Unfortunately, the units passed to
monotime_coarse_stamp_units_to_approx_msec() was always 0 due to a type
conversion.

Signed-off-by: David Goulet <dgoulet@torproject.org>
2018-04-16 15:05:41 -04:00
Nick Mathewson
1b31195b4f Fix "make check-spaces" 2018-04-13 16:31:47 -04:00
Nick Mathewson
003e6595bf Refactor "timestamp" not to be its own type coupled to token buffers
Really, the uint32_t is only an optimization; any kind of unit
should work fine.  Some users might want to use time_t or
monotime_coarse_t or something like that.
2018-04-13 16:31:47 -04:00
Nick Mathewson
0b40ed5e70 Start re-refactoring the token bucket interface.
Begin by creating a lowest-level triple of the types needed to
implement a token bucket: a configuration, a timestamp, and the raw
bucket itself.

Note that for low-level buckets, the units of the timestamp and the
bucket itself are unspecified: each user can use a different type.

(This patch breaks check-spaces; a later patch will fix it)
2018-04-13 16:31:47 -04:00
Nick Mathewson
03b96882de Rename token_bucket_t to token_bucket_rw_t.
This is a simple search-and-replace to rename the token bucket type
to indicate that it contains both a read and a write bucket, bundled
with their configuration.  It's preliminary to refactoring the
bucket type.
2018-04-13 10:54:26 -04:00
Nick Mathewson
787bafc0f9 Increase tolerances for imprecise time. 2018-04-13 10:41:15 -04:00
Nick Mathewson
3f514fe3b1 Accept small hops backward in the monotonic timer. 2018-04-13 10:41:15 -04:00
Nick Mathewson
c376200f6a Add a new token-bucket backend abstraction, with tests
This differs from our previous token bucket abstraction in a few
ways:

  1) It is an abstraction, and not a collection of fields.
  2) It is meant to be used with monotonic timestamps, which should
     produce better results than calling gettimeofday over and over.
2018-04-13 10:41:14 -04:00