-
Notifications
You must be signed in to change notification settings - Fork 535
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
Add best-effort stealing API to PollingSystem
#4113
base: series/3.x
Are you sure you want to change the base?
Conversation
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.
One thing I'm a bit concerned about with this approach is, without a concrete implementation and usage, it's hard to be 100% certain that this is actually the API we want. I would almost feel like we're better off deferring this change until we have the ability to actually use it. Since it's already an abstract class (rather than a trait), and it has a default implementation, we can do things like this compatibly after 3.6.
* whether any events were stolen. e.g. if the method returned due to timeout, this should | ||
* be `false`. | ||
*/ | ||
def steal(poller: Poller, reportFailure: Throwable => Unit): Boolean |
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.
Something that's a bit unclear in this API is whether poller
is what you're stealing from or to.
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.
Noted, although you always need somewhere to steal from. Also similar to timers we only steal completed events, so they don't need a destination heap / poller to be stolen to, this would be pretty challenging to implement anyway.
So it occurs to me that, because this method is abstract, it's going to be binary breaking if we do it post 3.6 unless we provide a default implementation. The fact that it's an abstract class rather than a trait doesn't really save us. |
Right, but because the API only promises best-effort stealing the default implementation can just be a no-op. |
Closes #4008.
I sketched out a possible stealing implementation for
Selector
along with a test but ended up reverting it because it's not possible to threadsafely interact with the selected keys set (without relying on synchronization, but this could mean the stealing thread being blocked indefinitely if the owner thread happens to be polling concurrently).Since we don't support multi-threading on Native yet, stealing for epoll/kqueue is implemented as no-op for now. I will investigate if we can implement stealing for those systems later on.
I'm still optimistic that we can support stealing for io_uring.