You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The pattern of keeping PkvStore as a resource is not compatible with offloading usage onto a task pool, because PkvStore cannot be cloned.
Is the intended usage to create a new PkvStore for tasks?
I don't think wrapping PkvStore in Arc<RwLock<_>> is a good solution because most (all?) storage backends do not require this extra layer of synchronization.
It seems like it would also be possible to change the StoreImpl trait to use &self instead of &mut self and rely on the interior mutability/synchronization of the database implementations. Then we could actually have a lazy-initialized static global database handle which can be used from anywhere. Or we could only wrap PkvStore in Arc and clone it out of the resource for tasks.
The text was updated successfully, but these errors were encountered:
The pattern of keeping
PkvStore
as a resource is not compatible with offloading usage onto a task pool, becausePkvStore
cannot be cloned.Is the intended usage to create a new
PkvStore
for tasks?I don't think wrapping
PkvStore
inArc<RwLock<_>>
is a good solution because most (all?) storage backends do not require this extra layer of synchronization.It seems like it would also be possible to change the
StoreImpl
trait to use&self
instead of&mut self
and rely on the interior mutability/synchronization of the database implementations. Then we could actually have a lazy-initialized static global database handle which can be used from anywhere. Or we could only wrapPkvStore
inArc
and clone it out of the resource for tasks.The text was updated successfully, but these errors were encountered: