search

typelevel / cats-effect

The pure asynchronous runtime for Scala
https://typelevel.org/cats-effect/
Apache License 2.0
2.01k stars 514 forks source link

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

Open armanbilge opened 6 months ago

armanbilge commented 6 months ago

This would mostly be to support cancelation with a similar mechanism used in the new timer heap introduced in https://github.com/typelevel/cats-effect/pull/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.

djspiewak commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

Reference equality? Here's how we do it for timers. https://github.com/typelevel/cats-effect/blob/769a89ef5d39f35d3a2cd00ffedbd22c91df48cc/core/jvm/src/main/scala/cats/effect/unsafe/WorkerThread.scala#L294-L295