Right now objects which are handed out from the pool keep a Weak reference to the pool but the pool has no way of referencing the Object. In order to implement the StatementCaches in deadpool-postgres I had to put the StatementCache of each object in an Arc and add the logic of keeping track of objects to the Manager itself.
It would be nice if the Pool kept a Weak reference to all objects. This would also allow for deeper introspection. e.g. accessing the metrics of objects which are in use by other workers.
The downside would be that all objects would now include an indirection via an Arc to the inner object even if it is never used. It would however open the library up for things like sharing objects:
196
It might make other features more complicated though as some objects need &mut self and wrapping it inside an Arc<T> would now require a Arc<Mutex<T>> which is a hefty price for code that doesn't need this:
226
Ideally there would be three implementations giving the user the choice:
Only one worker can access the actual object (that's how it is done today) providing Deref and DerefMut implementations
Only Deref is provided and the object needs to be Sync. This would allow sharing objects among multiple workers.
The object is wrapped inside a RwLock or Mutex adding extra overhead.
Alternatively the object could be split into two parts. The first part is the object itself which just needs to be Send and only one worker is allowed to access it. The other part consists of metrics and other pool specific things which can be accessed from multiple workers and is required to be Send + Sync.
This feature has been in my head for quite some time but I've never come around writing it down.
Right now objects which are handed out from the pool keep a
Weakreference to the pool but the pool has no way of referencing theObject. In order to implement theStatementCachesindeadpool-postgresI had to put theStatementCacheof each object in anArcand add the logic of keeping track of objects to theManageritself.It would be nice if the Pool kept a
Weakreference to all objects. This would also allow for deeper introspection. e.g. accessing the metrics of objects which are in use by other workers.The downside would be that all objects would now include an indirection via an
Arcto the inner object even if it is never used. It would however open the library up for things like sharing objects:196
It might make other features more complicated though as some objects need
&mut selfand wrapping it inside anArc<T>would now require aArc<Mutex<T>>which is a hefty price for code that doesn't need this:226
Ideally there would be three implementations giving the user the choice:
DerefandDerefMutimplementationsDerefis provided and the object needs to beSync. This would allow sharing objects among multiple workers.RwLockorMutexadding extra overhead.Alternatively the object could be split into two parts. The first part is the object itself which just needs to be
Sendand only one worker is allowed to access it. The other part consists of metrics and other pool specific things which can be accessed from multiple workers and is required to beSend + Sync.This feature has been in my head for quite some time but I've never come around writing it down.