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