Describe the bug
While trying to compile for mips-unknown-linux-musl, I discovered that prometheus does not compile on 32-bit targets due to the use of AtomicU64 in some internal timekeeping functionality.
To Reproduce
Steps to reproduce the behavior:
cargo build --target <some 32-bit target>
Expected behavior
Should compile on 32-bit targets
Additional context
I obviously don’t understand why the “recent” functionality in time.rs is necessary, which is the offender here. Using 32-bit atomics for the milliseconds is obviously a bad idea too. But maybe it would be acceptable to simply use a mutex or RwLock on 32-bit targets and take the perf hit?
Looking at it some more, it seems like this function is only used in LocalMetric::try_flush() — what is the reason for avoiding to call Instant::now() there? The function treats the returned timestamp as “now” anyways.
Describe the bug
While trying to compile for
mips-unknown-linux-musl, I discovered thatprometheusdoes not compile on 32-bit targets due to the use ofAtomicU64in some internal timekeeping functionality.To Reproduce
Steps to reproduce the behavior:
cargo build --target <some 32-bit target>Expected behavior
Should compile on 32-bit targets
Additional context
I obviously don’t understand why the “recent” functionality in
time.rsis necessary, which is the offender here. Using 32-bit atomics for the milliseconds is obviously a bad idea too. But maybe it would be acceptable to simply use a mutex orRwLockon 32-bit targets and take the perf hit?Looking at it some more, it seems like this function is only used in
LocalMetric::try_flush()— what is the reason for avoiding to callInstant::now()there? The function treats the returned timestamp as “now” anyways.