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

Failing test case for waiting on a reused FD. #69

Merged
merged 1 commit into from
Aug 16, 2023

Conversation

Math2
Copy link
Contributor

@Math2 Math2 commented Aug 16, 2023

Types of Changes

  • Failing test case.

Contribution

Notes

I think I found another problem. Probably related to the "lazy disarming" optimization.

IIUC, the selector can mistakenly assume that events for a certain FD are already being polled, but they aren't because the FD has been closed and reopened since last time.

The test case works if you comment out local.close.

I think it's triggering some other problem I was investigating, but not sure...

@ioquatix
Copy link
Member

IIUC, the selector can mistakenly assume that events for a certain FD are already being polled, but they aren't because the FD has been closed and reopened since last time.

Yeah, I saw some code in libev which was trying to work around this.

@ioquatix
Copy link
Member

Here are the notes:

/*
 * general notes about epoll:
 *
 * a) epoll silently removes fds from the fd set. as nothing tells us
 *    that an fd has been removed otherwise, we have to continually
 *    "rearm" fds that we suspect *might* have changed (same
 *    problem with kqueue, but much less costly there).
 * b) the fact that ADD != MOD creates a lot of extra syscalls due to a)
 *    and seems not to have any advantage.
 * c) the inability to handle fork or file descriptors (think dup)
 *    limits the applicability over poll, so this is not a generic
 *    poll replacement.
 * d) epoll doesn't work the same as select with many file descriptors
 *    (such as files). while not critical, no other advanced interface
 *    seems to share this (rather non-unixy) limitation.
 * e) epoll claims to be embeddable, but in practise you never get
 *    a ready event for the epoll fd (broken: <=2.6.26, working: >=2.6.32).
 * f) epoll_ctl returning EPERM means the fd is always ready.
 *
 * lots of "weird code" and complication handling in this file is due
 * to these design problems with epoll, as we try very hard to avoid
 * epoll_ctl syscalls for common usage patterns and handle the breakage
 * ensuing from receiving events for closed and otherwise long gone
 * file descriptors.
 */

We might need to be more pessimistic about the cache.

@ioquatix ioquatix merged commit 54b8352 into socketry:main Aug 16, 2023
9 of 22 checks passed
@ioquatix ioquatix mentioned this pull request Aug 16, 2023
3 tasks
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.

2 participants