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

Add API to polling system to attempt to get current poller without shifting #4009

Open
armanbilge opened this issue Feb 19, 2024 · 6 comments

Comments

@armanbilge
Copy link
Member

This would mostly be to support cancelation with a similar mechanism used in the new timer heap introduced in #3781. Specifically, using this API you can check if your current thread owns the poller you need to send the cancel to. If so, it can be done on a fast/simple happy-path, otherwise it will need to go through some concurrent-safe mechanism.

@armanbilge armanbilge added this to the v3.6.0 milestone Feb 19, 2024
@djspiewak
Copy link
Member

Just because I'm being dumb… Why do we need this again? async itself already fast-paths this type of scenario, so the only cost to unconditionally wrapping is a few allocations and a cede.

@armanbilge
Copy link
Member Author

async itself already fast-paths this type of scenario

The scenario we are concerned with here is not related to async actually. It relates to the cost of shifting onto the WSTP because you're not already there, just to obtain a poller that very likely isn't the one you wanted anyway.

@djspiewak
Copy link
Member

The scenario we are concerned with here is not related to async actually. It relates to the cost of shifting onto the WSTP because you're not already there, just to obtain a poller that very likely isn't the one you wanted anyway.

I'm definitely confused then. If you're not on the WSTP, then any fast-path to get the current poller would fail, so you'd end up with None/null anyway. My understanding of OP is that you wanted something which fast-paths the scenario where you're on the worker thread and you can get the current poller directly, synchronously. Is that not the case?

@armanbilge
Copy link
Member Author

armanbilge commented Apr 22, 2024

My understanding of OP is that you wanted something which fast-paths the scenario where you're on the worker thread and you can get the current poller directly, synchronously. Is that not the case?

Nope. The OP is exactly like the timers situation: suppose you are trying to cancel a timer. That doesn't mean that you need to get onto the WSTP so that you can safely access a timer heap. All you want to do is see if you have access to a heap on your current thread, and if so, if it is the one you want to manipulate. You don't want access to any heap, you want access to a very specific one if possible, otherwise you can use a fallback mechanism.

Same deal here. You want access to a very specific poller, not any poller, and if you can't immediately get that access, you want to fallback, not get rescheduled.

Currently there is no API that supports this for pollers. For timers there is.

@djspiewak
Copy link
Member

How would you envision identifying the poller? Like, you know you want a specific poller, but how would you communicate that to the API?

@armanbilge
Copy link
Member Author

Reference equality? Here's how we do it for timers.

private[unsafe] def ownsTimers(timers: TimerHeap): Boolean =
sleepers eq timers

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants