aboutsummaryrefslogtreecommitdiff
path: root/src/querymanager.hh
diff options
context:
space:
mode:
authorfusion32 <marcopuzziello@gmail.com>2025-10-16 01:35:10 -0300
committerfusion32 <marcopuzziello@gmail.com>2025-10-16 01:46:10 -0300
commit95022ca95b1d2792bae447d90694dcc0d67b9de2 (patch)
tree3a23505d31c48188f537a6da95239215a6487297 /src/querymanager.hh
parentb49d7de51cf14632a5768f292b870e647cf39bf5 (diff)
downloadquerymanager-95022ca95b1d2792bae447d90694dcc0d67b9de2.tar.gz
querymanager-95022ca95b1d2792bae447d90694dcc0d67b9de2.zip
lower monotonic uptime resolution from MILLISECONDS to SECONDS
The monotonic uptime was used exclusively with caches and having a resolution of SECONDS allows it to be stored as an int without risk of wrapping (~68 years). Using MILLISECONDS meant that it would wrap after ~25 days which is totally possible and EXPECTED. Just as an example, the small test server I ran for about 1 month had ZERO downtime on the QueryManager except for when I manually restarted it. It was probably very close to wrapping when I took it down.
Diffstat (limited to 'src/querymanager.hh')
-rw-r--r--src/querymanager.hh2
1 files changed, 1 insertions, 1 deletions
diff --git a/src/querymanager.hh b/src/querymanager.hh
index 46ea80d..220f69a 100644
--- a/src/querymanager.hh
+++ b/src/querymanager.hh
@@ -148,7 +148,7 @@ void LogAddVerbose(const char *Prefix, const char *Function,
struct tm GetLocalTime(time_t t);
struct tm GetGMTime(time_t t);
int64 GetClockMonotonicMS(void);
-int GetMonotonicUptimeMS(void);
+int GetMonotonicUptime(void);
void SleepMS(int DurationMS);
void CryptoRandom(uint8 *Buffer, int Count);
int RoundSecondsToDays(int Seconds);