RFC 0014: Cancelable sleep #16070
Draft
RFC 0014: Cancelable sleep #16070
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ysbaddaden
force-pushed
the
feature/rfc-14-cancelable-timers
branch
2 times, most recently
from
cdd9a84 to
c6ed7c7
Compare
Also `Fiber::TimeoutToken` and `Fiber::TimeoutResult`.
ysbaddaden
force-pushed
the
feature/rfc-14-cancelable-timers
branch
from
c6ed7c7 to
72c66d8
Compare
straight-shoota
approved these changes
Aug 8, 2025
|
Any chance to get some specs for this? |
|
Sure, here they come! |
- `Fiber::CancelationToken` instead of `TimeoutToken` so we can
internally reuse the mechanism for select regardless of the presence
of a timeout action
- `Fiber.sleep(Time::Span, & : CancelationToken -> TimeoutResult)`
instead of `.timeout`
- `Fiber#resolve_timer?(token : CancelationToken) : Bool` instead of
`#resolve_timeout?`
- `::sleep(Time::Span)` becomes a shortcut for `Fiber.sleep(Time::Span) { }`
- `Crystal::EventLoop#sleep(Time::Span, CancelationToken)` to replace
the existing method instead of introducing a new `#timeout` method
|
This pull request has been mentioned on Crystal Forum. There might be relevant details there: https://forum.crystal-lang.org/t/rfc-14-cancelable-timers/8386/1 |
|
Back to draft. There are things to resolve around "cancellation" that is more general than "canceling a timer". |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Initial attempt to implement RFC 0014 that aims to introduce a cancelable timer, designed to be low level, yet simple and efficient, allowing higher level abstractions, such as a pool of connections for example, to easily add timeout features.
I found an implementation gotcha (no impact on the RFC): we MUST synchronize when a fiber canceled the timeout while the event loop is running and has already dequeued the timer. Because the event/timer objects are allocated on the stack, so we must suspend again until the evloop has processed the timer (otherwise 💥) and the evloop must always enqueue. We could allocate on the HEAP as I had to do for libevent (no way to know if the event was deleted), but we'd have to always allocate because there wouldn't be any way to know if the event changed (and could cancel a new timeout using the new token 💣).
In practice the extra
Fiber.suspendshould be rare, and I feel better knowing that there are no side effects after thetimeoutreturns.I checked the internal usages for timeouts in the IOCP and Epoll/Kqueue event loops, and I'm pretty confident they could use (at least
Fiber#new_cancelation_token,Fiber#resolve_timer?with their internal#sleepimplementation, to avoid a Fiber -> EventLoop -> Fiber -> EventLoop dependency). I didn't check the usage in the select timeout action, yet, but I hope we can reuse the cancelation mechanism instead of the select state allocation (regardless of the presence of a timeout action).NOTE: this is untested, not even compilation. CI will likely fail all over 🙈Now fixed and verified on Linux (polling & libevent) and Windows (IOCP).