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

wtdcode · 2024-06-28T16:21:08Z

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 · 2024-06-28T16:23:48Z

@rakita Can we have this before #1574 ?

mattsse · 2024-06-29T08:06:24Z

crates/revm/src/db/utils.rs

+    {
+        match self {
+            Self::Handle(handle) => tokio::task::block_in_place(move || handle.block_on(f)),
+            Self::Runtime(rt) => rt.block_on(f),


this will panic if called within async execution context

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.

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 · 2024-06-29T08:11:09Z

crates/revm/src/db/ethersdb.rs

+    pub fn with_runtime(
+        client: Arc<M>,
+        block_number: Option<BlockId>,
+        runtime: Runtime,


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

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

DaniPopes

Makes sense

crates/revm/src/db/alloydb.rs

rakita

lgtm

jafar75 · 2024-06-30T13:24:44Z

crates/revm/src/db/ethersdb.rs


 use crate::primitives::{AccountInfo, Address, Bytecode, B256, U256};
 use crate::{Database, DatabaseRef};

 use super::utils::HandleOrRuntime;

-#[derive(Debug, Clone)]


@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

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?

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.

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:

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.

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:

Share a single Arc<Mutex<CacheDB<EthersDB>>> across all threads. This avoids duplicate caching for each thread and can speed up your application overall.

Clone CacheDB members (note they are public) except the EthersDB and create a new EthersDB instead. This generously is a manual "Clone" implementation.

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?

Note with_db accepts borrows.

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

wtdcode added 3 commits June 29, 2024 00:14

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

00adb4b

Minor fix and clippy

fda89ed

Clippy

f94b1b7

mattsse reviewed Jun 29, 2024

View reviewed changes

allow users to provide a runtime handle

ba20812

DaniPopes reviewed Jun 29, 2024

View reviewed changes

crates/revm/src/db/alloydb.rs Outdated Show resolved Hide resolved

wtdcode added 2 commits June 29, 2024 22:35

Update docs

e6c8a57

Fix slashes

01899bb

rakita approved these changes Jun 30, 2024

View reviewed changes

rakita merged commit 1fedacd into bluealloy:main Jun 30, 2024
26 checks passed

github-actions bot mentioned this pull request Jun 30, 2024

chore: release #1579

Merged

jafar75 reviewed Jun 30, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

wtdcode commented Jun 28, 2024 •

edited

Loading

wtdcode commented Jun 28, 2024

mattsse Jun 29, 2024

wtdcode Jun 29, 2024 •

edited

Loading

wtdcode Jun 29, 2024

mattsse Jun 29, 2024

wtdcode Jun 29, 2024

DaniPopes left a comment

rakita left a comment

jafar75 Jun 30, 2024

wtdcode Jun 30, 2024

jafar75 Jun 30, 2024

wtdcode Jun 30, 2024 •

edited

Loading

jafar75 Jun 30, 2024 •

edited

Loading

wtdcode Jun 30, 2024

jafar75 Jun 30, 2024 •

edited

Loading

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

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

Conversation

wtdcode commented Jun 28, 2024 • edited Loading

wtdcode commented Jun 28, 2024

Choose a reason for hiding this comment

wtdcode Jun 29, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DaniPopes left a comment

Choose a reason for hiding this comment

rakita left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wtdcode Jun 30, 2024 • edited Loading

Choose a reason for hiding this comment

jafar75 Jun 30, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jafar75 Jun 30, 2024 • edited Loading

Choose a reason for hiding this comment

wtdcode commented Jun 28, 2024 •

edited

Loading

wtdcode Jun 29, 2024 •

edited

Loading

wtdcode Jun 30, 2024 •

edited

Loading

jafar75 Jun 30, 2024 •

edited

Loading

jafar75 Jun 30, 2024 •

edited

Loading