Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Work around 32 bits epoll_wait() bug #1349

Merged
merged 1 commit into from
Sep 28, 2020
Merged

Work around 32 bits epoll_wait() bug #1349

merged 1 commit into from
Sep 28, 2020

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