Get Object from pool with priority
I was thinking, maybe it would be kind of nice to be able to specify a priority with a pool.get_with_priority(n), that way I can force some tasks which tend to hog the connections to use them less than others, but when the others don't need them, then they have full access to the database.
I suppose, just like a task priority proposal for tokio itself https://github.com/tokio-rs/tokio/issues/3150 (as mentioned https://github.com/tokio-rs/tokio/issues/3242#issuecomment-747765790 ), such a system is likely to want a custom scheduler to suite a specific application, so I guess that might might need to be considered?
The synchronization primitive is a tokio::sync::Semaphore which doesn't support an acquire_with_priority method. It's the only fair async semaphore implementation I'm aware of. async-lock isn't even fair at the moment:
- https://github.com/smol-rs/async-lock/issues/23
It's tempting to change the pool implementation from a passive pool to an active pool with a background worker. That would allow all sorts of fancy things. It would also add a non negligible amount of complexity to the project which I was always very careful not to add.
I have to think about this for a bit... :thinking:
I haven't looked into it in detail, but perhaps something like this could be achieved, at least proof of concept using a wrapper around the pool?
In theory it should be possible to implement this using a priority queue (binary heap) of Wakers. Though there are many dragons lurking and implementing a proper and well tested synchronization primitive is hard work. While working on deadpool I tried many different semaphore implementations. In the async space the one from tokio is the only one that is usable and even proven correct.
If anyone wants to give this a try I'd be glad to adopt this to deadpool and provide a new function fetching objects with priority from the pool. I'm curious how such synchronization primitive could look like and I'd be happy to assist in reviewing and testing such primitive.
Marking this issue blocked as this depends on a feature that isn't available in tokio, yet:
- tokio-rs/tokio#3242
I'm closing this for the time being as it is blocked by https://github.com/tokio-rs/tokio/issues/3242.