Skip to content

Add overwrite option to channel send to enable ring-buffer like behavior #82

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

Open
wants to merge 14 commits into
base: master
Choose a base branch
from

Conversation

elcritch
Copy link
Contributor

@elcritch elcritch commented Mar 26, 2025

In some cases it's useful to have a channel which acts as a ring-buffer that overwrites the oldest data.

For example in UIs you often want the last mouse input. The alternatives like calling tryRecv and then send require taking the lock multiple times and adds odd edge-cases.

Alternatively this could be made into a new proc sendOverwrite or forceSend as send(ch, val, overwrite=true) is no longer blocking in a sense.

@elcritch elcritch marked this pull request as ready for review March 26, 2025 00:53
@Araq
Copy link
Member

Araq commented Mar 26, 2025

forceSend or maybe push is the better API than a flag that changes behavior in a severe way.

@elcritch
Copy link
Contributor Author

elcritch commented Mar 26, 2025

forceSend or maybe push is the better API than a flag that changes behavior in a severe way.

I sorta like push. The forceSend would be good too. I updated it with push to see how it feels.

Claude gives me:

Based on the naming convention "push", I'd expect this method to have the following behavior:

  1. It would be non-blocking (like trySend).
  2. It would follow a "newest is most important" philosophy, which aligns with your need to prioritize new values.

In essence, push suggests a stack-like or priority operation where new items have precedence over old ones. This fits well with your requirement to overwrite older items instead of blocking.
So if I saw channel.push(val) in code, I'd assume it's implementing precisely the behavior you're looking for - a non-blocking send that overwrites older data when the channel is full.

@elcritch elcritch force-pushed the enable-ring-buffer-mode branch from 6f84519 to 3b4e858 Compare March 26, 2025 05:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants