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

Proposal: extract raw Ring Buffer structure out of channels module #22

Open
ZoomRmc opened this issue Feb 11, 2023 · 3 comments
Open

Proposal: extract raw Ring Buffer structure out of channels module #22

ZoomRmc opened this issue Feb 11, 2023 · 3 comments

Comments

@ZoomRmc
Copy link
Contributor

ZoomRmc commented Feb 11, 2023

While doing refactoring of channels (#21), I've separated all the raw ring/circular buffer logic into it's own object and put it in a module. I think this could prove useful:

  • Separation of concern => more succinct, easily readable and testable code.
  • Current channel implementation just adds locking around enqueue/dequeue ops and fullness checks, so there's nothing invasive which could prevent separation.
  • Having a separate module for a basic data structure could provide a basis for a public-facing typed version easily (the only real work necessary is a JS version, which can't use any raw memory ops).

I can start with just having a separate object in the same module, and if this channel implementation stabilizes, it can be moved out and open the ways of using the basic data structure in other places.

@Araq
Copy link
Member

Araq commented Feb 14, 2023

Ok, go for it.

@elcritch
Copy link
Contributor

@ZoomRmc did you ever end up doing this? It'd be handy. I modified channel to support overwrite operation in the ring buffer, but it'd be nice to be able to swap out the ring-buffer logic or otherwise tweak it.

@ZoomRmc
Copy link
Contributor Author

ZoomRmc commented Nov 14, 2023

@ZoomRmc did you ever end up doing this?

I had worked something out in a private repo, but as I recall the current channels implementation prevents reusing a generic ringbuffer so I didn't pursue merging in the basic data structure further.

IIRC the issue is that channels here try to do do many things at once so have a bit of branching inside basic operations. I didn't close the issue as I still think it could be beneficial and also wasn't sure how long the current channels' impl stays unchanged.

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

No branches or pull requests

3 participants