feat: add Pool type for pooling plugin instances #696
Conversation
|
I am currently implementing Extism plugin support for Lemmy, which is a web server that definitely requires concurrency support for performance reasons. So thanks a lot for this feature! I will give some feedback based on my implementation with this PR. You can see the current code in this pull request and specifically this file. The main thing thats missing currently is a function |
|
|
||
| /// `Pool` manages threadsafe access to a limited number of instances of multiple plugins | ||
| #[derive(Clone)] | ||
| pub struct Pool<Key: std::fmt::Debug + Clone + std::hash::Hash + Eq = String> { |
There was a problem hiding this comment.
Im not sure what the Key parameter is good for. It may be useful to store multiple different plugin types in the same pool, but this is tricky as there is currently no way to get a list of all existing keys. Anyway the pool itself has very little overhead, so it makes more sense for users to write HashMap<Key, Pool> if needed. In my case Im using Vec<Pool<()>> because there is no need for any hashmap.
|
@Nutomic thanks for the review! I like the suggestion about moving the map out of |
|
Are you planning to finish this PR and merge it? Our corresponding feature is already merged using this code as git dependency (LemmyNet/lemmy#5498). Our stable release is still some months away, by then it would be good to depend on a stable extism version with this included. |
|
Hi @Nutomic - I think we could release this code, especially if it's already working for you. I will try to address your feedback and get this into a mergeable state in the next few weeks. |
…stances being created
|
Hi @Nutomic - I've addressed most of your feedback, with the exception of removing the |
|
Yes that sounds good, the main thing is to get this merged. |
Poolallows for a configurable number of instances for each plugin and will block waiting for a plugin to become available if the limit is reached