Skip to content

Conversation

@bnoordhuis
Copy link
Contributor

A bug in kernels < 2.6.37 makes timeouts larger than LONG_MAX /
CONFIG_HZ (approx. 30 minutes with CONFIG_HZ=1200) effectively
infinite on 32 bits architectures. The magic number is the same
constant used by libuv, see commit libuv/libuv@d1b5008e76.

If you don't care about kernels that old, I'm a-okay with closing this. No hard feelings.

@Thomasdezeeuw
Copy link
Collaborator

Officially we don't support kernels that old. That said since the change is rather small I would be OK with it it. @carllerche, @kleimkuhler what are your thoughts?

@bnoordhuis to fix the CI you can use the following patch. It's complaining about cfg! not being constant.

diff --git a/src/sys/unix/selector/epoll.rs b/src/sys/unix/selector/epoll.rs
index eb7cbe3..6955848 100644
--- a/src/sys/unix/selector/epoll.rs
+++ b/src/sys/unix/selector/epoll.rs
@@ -49,11 +49,11 @@ impl Selector {
         // A bug in kernels < 2.6.37 makes timeouts larger than LONG_MAX / CONFIG_HZ
         // (approx. 30 minutes with CONFIG_HZ=1200) effectively infinite on 32 bits
         // architectures. The magic number is the same constant used by libuv.
-        const MAX_SAFE_TIMEOUT: u128 = if cfg!(target_pointer_width = "32") {
-            1789569
-        } else {
-            libc::c_int::max_value() as u128
-        };
+        #[cfg(target_pointer_width = "32")]
+        const MAX_SAFE_TIMEOUT: u128 = 1789569;
+        #[cfg(not(target_pointer_width = "32"))]
+        const MAX_SAFE_TIMEOUT: u128 = libc::c_int::max_value() as u128;
 
         let timeout = timeout
             .map(|to| cmp::min(to.as_millis(), MAX_SAFE_TIMEOUT) as libc::c_int)

A bug in kernels < 2.6.37 makes timeouts larger than LONG_MAX /
CONFIG_HZ (approx. 30 minutes with CONFIG_HZ=1200) effectively
infinite on 32 bits architectures. The magic number is the same
constant used by libuv, see commit libuv/libuv@d1b5008e76.
@carllerche
Copy link
Member

👍

@carllerche carllerche merged commit d555991 into tokio-rs:master Sep 28, 2020
@Thomasdezeeuw
Copy link
Collaborator

Thanks @bnoordhuis

@Thomasdezeeuw
Copy link
Collaborator

@carllerche is this something we want to backport to v0.6?

Thomasdezeeuw pushed a commit to Thomasdezeeuw/mio that referenced this pull request Sep 29, 2020
A bug in kernels < 2.6.37 makes timeouts larger than LONG_MAX /
CONFIG_HZ (approx. 30 minutes with CONFIG_HZ=1200) effectively
infinite on 32 bits architectures. The magic number is the same
constant used by libuv, see commit libuv/libuv@d1b5008e76.
Thomasdezeeuw pushed a commit to Thomasdezeeuw/mio that referenced this pull request Dec 1, 2020
A bug in kernels < 2.6.37 makes timeouts larger than LONG_MAX /
CONFIG_HZ (approx. 30 minutes with CONFIG_HZ=1200) effectively
infinite on 32 bits architectures. The magic number is the same
constant used by libuv, see commit libuv/libuv@d1b5008e76.
Thomasdezeeuw pushed a commit that referenced this pull request Dec 1, 2020
A bug in kernels < 2.6.37 makes timeouts larger than LONG_MAX /
CONFIG_HZ (approx. 30 minutes with CONFIG_HZ=1200) effectively
infinite on 32 bits architectures. The magic number is the same
constant used by libuv, see commit libuv/libuv@d1b5008e76.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants