-
Notifications
You must be signed in to change notification settings - Fork 14
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
Request: standalone EBR implementation #131
Labels
enhancement
New feature or request
Comments
Looks like a great idea! Right now, I’m way too busy to make big changes to the crate, but I’ll definitely do this in the long run. |
FYI: published https://crates.io/crates/sdd / source: https://github.com/wvwwvwwv/scalable-delayed-dealloc => This will be integrated into it next month. |
wvwwvwwv
added a commit
that referenced
this issue
Apr 17, 2024
Thanks a lot! |
loyd
added a commit
to loyd/idr-ebr
that referenced
this issue
Apr 21, 2024
`scc::ebr` was moved to the dedicated crate `sdd`: wvwwvwwv/scalable-concurrent-containers#131
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I appreciate your implementation of EBR and plan to incorporate it into future projects, specifically for implementing a slab structure. However, I have concerns regarding the
scc
dependency potentially becoming heavy. Consequently, I would prefer to rely on a more lightweight crate.Additionally, segregating EBR into its own dedicated crate would help
scc
's evolution, including potential breaking changes (e.g. #105). This separation allows for the coexistence of multiplescc
versions (such as v2, v3, etc.) within the same project, each using the same collectors. A similar modular approach is already used across the ecosystem (e.g.,signal_hook
andsignal_hook_registry
crates).So, what do you think about publishing
scc-ebr
and movingscc
to use it?The text was updated successfully, but these errors were encountered: