No support for 32-bit platforms (e.g. armv5te)

[LEXUGE]

I am wishing to ship a program with governor to armv5te target. However, due to the fact that AtomicU64 doesn't exist on the target, I am getting the following:

   |
56 | pub use std::sync::atomic::{AtomicI64, AtomicU64};
   |                             ^^^^^^^^^  ^^^^^^^^^ no `AtomicU64` in `sync::atomic`
   |                             |
   |                             no `AtomicI64` in `sync::atomic`
   |
help: a similar name exists in the module
   |
56 | pub use std::sync::atomic::{AtomicI8, AtomicU64};
   |                             ^^^^^^^^
help: a similar name exists in the module
   |
56 | pub use std::sync::atomic::{AtomicI64, AtomicU8};
   |                                        ^^^^^^^^

Is there anyway to work around?

[antifuchs]

Oof. I'm sorry, but governor is currently limited to native 64-bit time representations, being nanosecond counts... 32bit just aren't wide enough to hold the number of nanoseconds required for any useful rate-limiting, I'm afraid (you could only measure time intervals 4 seconds long).

I think it might be possible to maybe work around this, by introducing a clock that has a more coarse "resolution" - that is, instead of nanoseconds, it returns e.g., microseconds (good for 4000 seconds, so about 1/5 day), or a millisecond even, that's 49 days. I imagine that would be useful for more limited platforms, and it would also need a better handling of the validity of rate-limiters: they currently panic if the time interval gets exceeded - on 64-bit platforms, after 200-some years if you use nanosecond resolution... on 32-bit platforms, way earlier.

So - it's not a completely hopeless cause, but currently there is no trivial way to get support for a 32-bit platform: a hopeful user would have to tear through the clock and Nanos abstraction and introduce the resolution concept.

[LEXUGE]

Can quanta work on mips and mipsel then? Will it require mips64 and mips64el to compile?

[antifuchs]

Quanta might work! I'm not sure what they use internally, it might be possible they use a different representation on 32-bit platforms... but if not, then it's not going to work, either.

[LEXUGE]

Seems like there are some updates in quanta metrics-rs/quanta#55

[decaz]

@antifuchs are there any plans to resolve this? For instance Crossbeam has special configuration flag for such kind of problem: crossbeam_no_atomic_64 (crossbeam-rs/crossbeam#731). Maybe it is possible to implement similar flag here..

[hgy59]

I have the same issue when building vaultwarden for ARMv5 (RUST_TARGET=armv5te-unknown-linux-gnueabi):

full stack:

  Installing vaultwarden v1.0.0 (/spksrc/spk/vaultwarden/work-88f6281-6.1/vaultwarden-1.25.0)
    Updating git repository `https://github.com/BlackDex/job_scheduler`
    Updating crates.io index
   Compiling governor v0.4.2
   Compiling cookie_store v0.15.1
error[E0432]: unresolved import `std::sync::atomic::AtomicU64`
  --> /spksrc/distrib/cargo/registry/src/github.com-1ecc6299db9ec823/governor-0.4.2/src/clock.rs:53:5
   |
53 | use std::sync::atomic::AtomicU64;
   |     ^^^^^^^^^^^^^^^^^^^---------
   |     |                  |
   |     |                  help: a similar name exists in the module: `AtomicU8`
   |     no `AtomicU64` in `sync::atomic`

error[E0432]: unresolved import `std::sync::atomic::AtomicU64`
 --> /spksrc/distrib/cargo/registry/src/github.com-1ecc6299db9ec823/governor-0.4.2/src/state/in_memory.rs:8:5
  |
8 | use std::sync::atomic::AtomicU64;
  |     ^^^^^^^^^^^^^^^^^^^---------
  |     |                  |
  |     |                  help: a similar name exists in the module: `AtomicU8`
  |     no `AtomicU64` in `sync::atomic`

error[E0283]: type annotations needed
   --> /spksrc/distrib/cargo/registry/src/github.com-1ecc6299db9ec823/governor-0.4.2/src/clock.rs:129:5
    |
127 | #[derive(Debug, Clone, Default)]
    |                        ------- in this derive macro expansion
128 | pub struct FakeRelativeClock {
129 |     now: Arc<AtomicU64>,
    |     ^^^^^^^^^^^^^^^^^^^ cannot infer type
    |
    = note: cannot satisfy `_: std::default::Default`
    = note: this error originates in the derive macro `Default` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0283]: type annotations needed
  --> /spksrc/distrib/cargo/registry/src/github.com-1ecc6299db9ec823/governor-0.4.2/src/state/in_memory.rs:21:26
   |
20 | #[derive(Default)]
   |          ------- in this derive macro expansion
21 | pub struct InMemoryState(AtomicU64);
   |                          ^^^^^^^^^ cannot infer type
   |
   = note: cannot satisfy `_: std::default::Default`
   = note: this error originates in the derive macro `Default` (in Nightly builds, run with -Z macro-backtrace for more info)

Some errors have detailed explanations: E0283, E0432.
For more information about an error, try `rustc --explain E0283`.
error: could not compile `governor` due to 4 previous errors
warning: build failed, waiting for other jobs to finish...
error: failed to compile `vaultwarden v1.0.0 (/spksrc/spk/vaultwarden/work-88f6281-6.1/vaultwarden-1.25.0)`, intermediate artifacts can be found at `/spksrc/spk/vaultwarden/work-88f6281-6.1/vaultwarden-1.25.0/target`
make[3]: *** [../../mk/spksrc.cross-rust.mk:124: rust_build_and_install_target] Error 101
make[3]: Leaving directory '/spksrc/cross/vaultwarden'
make[2]: *** [../../mk/spksrc.depend.mk:54: depend_target] Error 2
make[2]: Leaving directory '/spksrc/spk/vaultwarden'
make[1]: *** [../../mk/spksrc.spk.mk:564: build-arch-88f6281-6.1] Error 1
make[1]: Leaving directory '/spksrc/spk/vaultwarden'
make: *** [../../mk/spksrc.spk.mk:558: arch-88f6281-6.1] Error 2