-
Notifications
You must be signed in to change notification settings - Fork 478
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
crossbeam_channel::tick delivery_time can support different flavor #989
Comments
What API are you proposing to add? |
@taiki-e that's the next step. If the semantic is good to have, I think the best way to express the API is by submitting a patch :D I file this issue first to avoid wasting time on patches that would never be accepted. |
I didn't mean to ask you to create a patch before the discussion about API, I wanted to know what you are imagining it would look like if it were expressed as an API in Rust. I guess what you are actually requesting here is something like tokio::time::interval, but tokio::time::interval also has an API to tune the behavior. |
@taiki-e Thanks for your information! Yes, it seems like For API in crossbeam channel, the whole structure can be identical to
If we agree on reuse the structure, it can be a different API on
|
Currently, the new delivery_time is calculated as:
crossbeam/crossbeam-channel/src/flavors/tick.rs
Lines 47 to 50 in dfafb46
But it can be a flavor config like Java's
ScheduledExecutorService
:scheduleAtFixedRate
andscheduleWithFixedDelay
.The current flavor is in
scheduleWithFixedDelay
, while replacenow + self.duration
withdelivery_time + self.duration
can simulatescheduleAtFixedRate
as much as possible.To consume multiple ticks backlog, one can use
try_iter
and thencollect
.Let me know if it's a good idea to follow. cc @taiki-e
The text was updated successfully, but these errors were encountered: