-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Command::output panics on Linux if more than 1024 file descriptors are open #40894
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
Comments
Wow. Times like this are when I'm super glad we use rust, otherwise this'd be a super weird segfault! We should probably just do epoll/kqueue and/or fall back to spawning threads when this happens. |
@matklad out of curiosity how'd you discover this? |
You could also just use poll for maximum compatibility. |
It's better to ask @knsd :)
Looks like poll does not always work on mac: https://daniel.haxx.se/blog/2016/10/11/poll-on-mac-10-12-is-broken/. Perhaps it does not matter in this simple case of two file descriptors without timeouts. |
This gives us the benefit of supporting file descriptors over the limit that select supports, which... Closes rust-lang#40894
std: Use `poll` instead of `select` This gives us the benefit of supporting file descriptors over the limit that select supports, which... Closes #40894
Under Linux this could have also been solved by allocating a dynamic bitmap as fdset. That way you can easily watch hundreds of thousands of filedescriptors using plain 'select'. Note that watching fdsets with filedescriptors higher than 8192 or so would see increasing runtime overhead, as the kernel has to scan the bitmap for possible fds to watch on each call to select. |
Issue originally reported by @knsd.
Command::open
usesselect
on Linux:rust/src/libstd/sys/unix/pipe.rs
Line 90 in 4465f22
select
is limited to file descriptors less thanFD_SETSIZE
(1024).Thus, if you raise
ulimit -n
to more than 1024, the following code panicsThe text was updated successfully, but these errors were encountered: