#Async strategy pattern

27 messages · Page 1 of 1 (latest)

copper thorn
#

I want a RwLock, which only holds anything T, while methods calls on T need to be dispatched dynamically. T needs to satisfy a trait for this.
Furthermore, the RwLock will implement one of my traits, but only, if it contains a value of type T.

It is something like an "async strategy pattern".

tldr: (pseudocode)

T; has to implement MyFunctionTrait
Vec<RwLock<T>>; RwLock<T> has to implement MyMethodTrait

I do not care, waht happens with RwLock<Q>because I will never have one.

Below is a playground which shows an example. I could not get it to compile. Can someone fix it for me and tell me, how to do it correctly?

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=aeeffcc8d6d191364fa6e1cb6645592b

#

Async visitor pattern

copper thorn
#

Async strategy pattern

mortal canyon
#

RwLock<dyn MyFunctionTrait>: MyMethodTrait doesn't work because MyFunction trait doesn't contain any info about what it should do, making it dyn erases everything that made it possible to call MyMethodTrait methods, which are defined on individual types

copper thorn
copper thorn
#

As already said in the question: this is something like an "async strategy pattern"

#

If it was not async, I could just drop the RwLock and everything would be way easier with just T

mortal canyon
#

I didn't change any comments so they might be confusing now

#

and I don't really know why Foo requires the T to be the inner trait instead of the outer one

#

I left it like that because that's what you had

#

it could just be struct Foo { handlers: Vec<Arc<dyn Schedule>> }

copper thorn
#

You can change anything, as long, as I can call any method provided by MyMethodTrait on the RwLock of T and any function of MyFuctionTrait on T.

So feel free to change it, and tell me, why and how 🙃
Only the general behaviour needs to stay, as mentioned above

#

I will have a look on your playground later

mortal canyon
#

you'll never be able to call functions on dyn MyFunctionTrait, because it has no methods

#

dyn MyFunctionTrait existing at all is nonsensical

copper thorn
# mortal canyon you'll never be able to call functions on `dyn MyFunctionTrait`, because it has ...

it does not have functions right now, yes, but I could (and will) add some. as I wrote in the comment in that trait

// this trait does not have any methods, only functions
    // which functions, does not matter

I could update the code like this:

pub trait MyFunctionTrait where RwLock<Self>: MyMethodTrait {
    fn foo() -> String;
}

and then call T::foo() for every entry of my vec. (I need to implement the trait vor One Two and Three before doing that however)

#

so MyFunctionTrait has its use, I just did not give it any functions in the playground example

#

in your example, lines 16-18 can not exist as they do, because the locking of the RwLock MUST be done inside of the called methods of MyMethodTrait to be able to run them concurrently.
these methods will be more complex, and may have a runtime of several minutes, so I have to make sure to hold locks as short as possible. if I obtain the locks before running the function, I will run into problems

#

The methods of MyMethodTrait have a self param, which always needs to be a RwLock<T>, so I can lock it when needed

copper thorn
mortal canyon
#

but you figured it out in the end

#

yeah also #[async_trait] is required to work with dyn