Use HandleOrRuntime to allow alloydb/ethersdb to hold a custom runtime

[wtdcode]

Following advice from @DaniPopes, this PR introduce HandleOrRuntime for both EthersDB and AlloyDB to avoid creating runtime for every call. Compared to #1557, this implementation also allows synchronous code to continue using both implementation by calling AlloyDB::with_runtime(..., ..., new_current_thread()), which reduces break changes.

This PR shall address the concerns of @DaniPopes while keeping the compatibility.

• If we are already in a tokio runtime, like foundry, the handle will be perfectly valid, and no runtime is created.
• If we are in synchronous code, users are responsible for creating the runtime only once for with_runtime.

Note with this PR, we could also support current thread runtime now.

[wtdcode]

@rakita Can we have this before #1574 ?

[mattsse]

this will panic if called within async execution context

[wtdcode]

Yes, that’s intended. Passing a runtime mostly would be the sync code. If user is within async execution context, they should call new directly instead.

[wtdcode]

As stated above, if user is in async context, they should call new as #1557 suggests. If user is in sync context, they should provide a runtime, mostly current_thread runtime.

If user intends to mix different contexts, they should be careful by themselves as it is known to be bad practice and cause problems hard to tackle.

[mattsse]

so the caller is responsible for creating a new runtime?
in which case they could also pass in the handle?

[wtdcode]

Make sense, we can add a new function and document the behavior.

[DaniPopes]

Makes sense

[rakita]

lgtm

[jafar75]

@wtdcode would you explain why Clone has been removed? I'm slightly new in Rust and want to learn the technical concept behind this decision

[wtdcode]

Because runtime doesn’t implement Clone and it doesn’t make too much sense cloning the db. Or, you could wrap it with an Rc or Arc.
What’s your use case?

[jafar75]

thanks
In my case, I define an ethersDB instance and by using it, I define a cacheDB. I add some base data (deploy contract, change some slots, etc) to cacheDB and after that, by cloning it, I send the same copies to multiple threads.

For now, I get an error (when cloning cacheDB) complains about ethersDB (as internal object of cacheDB) cannot be cloned.

because inside separate threads, I need to write to db, I tested not cloning and use Arc/Mutex. but the performance was worse than cloning.

[wtdcode]

thanks In my case, I define an ethersDB instance and by using it, I define a cacheDB. I add some base data (deploy contract, change some slots, etc) to cacheDB and after that, by cloning it, I send the same copies to multiple threads.

For now, I get an error (when cloning cacheDB) complains about ethersDB (as internal object of cacheDB) cannot be cloned.

because inside separate threads, I need to write to db, I tested not cloning and use Arc/Mutex. but the performance was worse than cloning.

It's not really make sense to clone AlloyDB or EthersDB. Clone was also added by me in a previous PR, but I recently found it was a mistake. Generally, it is due to:

1. Both Provider and Middleware are only safe to clone within the same runtime. If you send it across runtimes (or threads), many internal things and assumptions could break.
2. Even if ensure you are in the same async context all the time or just sync code, it just doesn't make sense to clone the EthersDB because it saves nothing.

To your use case which is similar to mine, my suggestion is:

1. Share a single Arc<Mutex<CacheDB<EthersDB>>> across all threads. This avoids duplicate caching for each thread and can speed up your application overall.
2. Clone CacheDB members (note they are public) except the EthersDB and create a new EthersDB instead. This generously is a manual "Clone" implementation.

[jafar75]

thanks, I have a challenge in using arc.

in order to create evm and then transact(), I must do lock. but, about all of my perf. overhead is related to these steps, so it convert my program in a literally single-threaded system.
do you have any suggestion for this case?

[wtdcode]

Note with_db accepts borrows.

[jafar75]

you mean with_ref_db ? I want to update the cache in each transact from multiple threads