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

crossbeam_channel::tick delivery_time can support different flavor #989

Open
tisonkun opened this issue Jun 14, 2023 · 4 comments
Open

crossbeam_channel::tick delivery_time can support different flavor #989

tisonkun opened this issue Jun 14, 2023 · 4 comments

Comments

@tisonkun
Copy link

Currently, the new delivery_time is calculated as:

if self
.delivery_time
.compare_exchange(delivery_time, now + self.duration)
.is_ok()

But it can be a flavor config like Java's ScheduledExecutorService: scheduleAtFixedRate and scheduleWithFixedDelay.

The current flavor is in scheduleWithFixedDelay, while replace now + self.duration with delivery_time + self.duration can simulate scheduleAtFixedRate as much as possible.

To consume multiple ticks backlog, one can use try_iter and then collect.

Let me know if it's a good idea to follow. cc @taiki-e

@taiki-e
Copy link
Member

taiki-e commented Jun 15, 2023

What API are you proposing to add?

@tisonkun
Copy link
Author

tisonkun commented Jun 16, 2023

@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.

@taiki-e
Copy link
Member

taiki-e commented Jun 17, 2023

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.

@tisonkun
Copy link
Author

@taiki-e Thanks for your information!

Yes, it seems like tokio::time::interval while I don't find your comment "has an API to tune the behavior". It seems that struct has only a period arg to define the interval.

For API in crossbeam channel, the whole structure can be identical to tick with different rules for calculating delivery_time, i.e.,

  • for try_recv, it's delivery_time + self.duration over now + self.duration.
  • for recv, it's delivery_time + self.duration over delivery_time.max(now) + self.duration.

If we agree on reuse the structure, it can be a different API on crossbeam_channel to switch the flavor,

  • tick_with_delay supersedes the current manner;
  • tick_with_interval indicates the proposed manner.

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

No branches or pull requests

2 participants