-
Notifications
You must be signed in to change notification settings - Fork 739
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
Use epoll_create() as a fallback for epoll_create1() #1590
Conversation
40d581a
to
baee477
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@link2xt as I've said it can't impact the performance of existing code, which this does. This will not be accepted as is.
@Thomasdezeeuw How does this impact the performance? Is epoll_create such a frequent operation that not calling fcntl saves any cycles? The crate doesn't have any benchmark, how do you measure it? |
I'm not willing to revert to |
Threre is zero difference in syscall implementation, both call The only difference is that there is an additional |
Can I just say that this is becoming really tiring... They reason that |
Is there any particular reason we can't use what the |
Sounds good, and should not degrade performance at all thanks to branch prediction: on systems with |
I think that would be fair to do. It shouldn't degrade performance or worsen anything for system which support the newer API, and would provide support for the older systems. |
That should fine with the addition of some documentation that we fall back to a racy version using |
Note that |
True, but for kqueue we can't do better (except for NetBSD, but that's not a tier1 platform for Mio). |
I have updated the PR to use |
Hmm, I don't think this works. I think you need to use the |
src/sys/unix/selector/epoll.rs
Outdated
#[cfg(debug_assertions)] | ||
has_waker: AtomicBool::new(false), | ||
}) | ||
syscall!(syscall(libc::SYS_epoll_create1, flag)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is probably even faster, because we no longer use epoll_create1
C function, but epoll_create1
syscall.
Fails on Illumos currently, because they have |
Illumos does not have epoll syscalls.
It's fixed now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is going into the right direction. However we're not going to use raw system calls. Also please add the the documentation to Poll::new
to I asked for regarding the possible data race.
src/sys/unix/selector/epoll.rs
Outdated
|
||
// Try epoll_create1 syscall with an epoll_create fallback. | ||
#[cfg(not(any(target_os = "illumos", target_os = "redox")))] | ||
let ep = syscall!(syscall(libc::SYS_epoll_create1, flag)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're not going to use raw system calls. Please add the epoll_create1
function the libc crate instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem it started with is that Android API level 16 does not have epoll_create1
library function in the libc, so the linker fails if we call epoll_create1
libc function. The solution is to try calling raw system call epoll_create1
and use a fallback if it falls with ENOSYS
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my case the linker is not even called by cargo, because cargo is only used to build static .a
library, so there is no way to detect whether libc has an epoll_create
function from within the compiler.
Is there any problem with using a raw system call?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any problem with using a raw system call?
It makes maintenance harder.
But I guess we can make an exception here, could you extract the system call stuff to a new epoll_create1
function, that for platforms that support it call libc::epoll_create1
and for others use the raw system interface?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did it, made a new_epoll_fd()
function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Almost their I think, I'm still not super happy about using raw system calls, but if we can minimise the usage to just Android I think it would be acceptable.
src/sys/unix/selector/epoll.rs
Outdated
let ep = syscall!(epoll_create1(flag))?; | ||
|
||
// Try epoll_create1 syscall with an epoll_create fallback. | ||
#[cfg(not(any(target_os = "illumos", target_os = "redox")))] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you change this to be android only with a comment referring to #1473 and explaining that Android API level 16 doesn't define epoll_create1
. I really like to minimise the use of raw system calls.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pushed a commit limiting this code to target_os = "android"
.
I'm going to merge this as and will do a little cleanup and more docs into another pr. |
Fixes #1473