GetTimeMillis
has multiple issues:
- It doesn’t denote the underlying clock type
- It isn’t type-safe
- It is used incorrectly in places that should use a steady clock
Fix all issues here.
GetTimeMillis
has multiple issues:
Fix all issues here.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
See the guideline for information on the review process.
Type | Reviewers |
---|---|
ACK | willcl-ark, martinus |
Concept ACK | dergoegge, fanquake, RandyMcMillan |
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
No conflicts as of last run.
35@@ -36,8 +36,8 @@ static Proxy nameProxy GUARDED_BY(g_proxyinfo_mutex);
36 int nConnectTimeout = DEFAULT_CONNECT_TIMEOUT;
37 bool fNameLookup = DEFAULT_NAME_LOOKUP;
38
39-// Need ample time for negotiation for very slow proxies such as Tor (milliseconds)
40-int g_socks5_recv_timeout = 20 * 1000;
41+// Need ample time for negotiation for very slow proxies such as Tor
42+std::chrono::milliseconds g_socks5_recv_timeout{20};
I think this should be 20s
. I guess in this case it might be safer to write
0std::chrono::milliseconds g_socks5_recv_timeout = 20s;
because just
0std::chrono::milliseconds g_socks5_recv_timeout = 20;
would give you a compile error
ACK fa83fb3161
This is a nice cleanup to the clocks.
There are a few time values left as other types in the codebase, but it doesn’t make sense to change them as they are being used as those types by other components (mainly libevent it seems).