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

Allow replacing the locking strategy #35

Closed
vorner opened this issue Jul 22, 2020 · 0 comments
Closed

Allow replacing the locking strategy #35

vorner opened this issue Jul 22, 2020 · 0 comments
Assignees

Comments

@vorner
Copy link
Owner

vorner commented Jul 22, 2020

Currently, it is possible to tune the generation locks using a trait. But the current lightweight hazard-pointer like debts are hard-coded.

Nevertheless, it seems it could be nice to be able to tune these too ‒ see #34 for examples where someone might want to pick different trade offs (faster reads at the cost of platform dependence and delayed destruction, for example).

Furthermore, we might want to defer the signal-safety into the locking strategy too and get rid of one of the niche methods on the main type.

So the goal here is to have a look if the whole locking strategy could be abstracted by a trait instead; it would replace the current second type parameter of the ArcSwapAny.

That really should happen before going 1.0, as this is API breaking. Implementing other strategies might wait after that, but we should be confident it is possible to do so.

@vorner vorner mentioned this issue Jul 22, 2020
5 tasks
@vorner vorner self-assigned this Aug 22, 2020
@vorner vorner closed this as completed Nov 22, 2020
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

1 participant