Why not having an async Database trait?
wtdcode opened this issue · comments
Reading through #554 and #1534 , I notice that the root cause is that current revm doesn't have async traits.
Given the fact that we already split the original single Database trait into both Database and DatabaseRef traits, can we have another trait like DatabaseAsync (and maybe DatabaseRefAsync) by using https://github.com/dtolnay/async-trait ? In this case:
- All databases implemented
Databaseimmediately getDatabaseAsyncimplemented by simply forwarding function calls. However, implementingDatabaseAsyncdoesn't implyDatabasetrait. - Current ethersdb/alloydb can have a more clean and reasonable implementation because the functions like
basicisasyncnow. And they will no longer implementDatabase. - This avoids confusion like: Does this
Databaseimplementation play with async world?
Generally, the modification is a bit huge because we need to add new async API since transact() and many places to support the async trait. Thus, I'm opening the issue for discussion before starting to work on it.
The new API style may be similar to reqwest, btw.
Appreciate if async db trait feature can be done. I used to fork and modify it to async for v3.5.0. And it's more difficult to do the same thing for the latest version.
tokio::task::block_in_place is not the elegant way. Underhood, it coerces current thread to a blocking thread while spawning a new worker thread. In other words, the overhead (in worst cases) can be as much as spawning a current_thread runtime.
this can be optimized by adding another variant that does not use block in place for every call.
but it's unreasonable to make entire evm execution async hence there's no async variant
this can be optimized by adding another variant that does not use block in place for every call.
I understand your solution because I once also tried to dedicate futures to standalone runtimes, which can also be achieved by my previous PR. It works and generally should be the intended solution as suggested by tokio documents.
but it's unreasonable to make entire evm execution async hence there's no async variant
I agree that evm exution is sync by nature but the db access is not, no?
This also reminds me of another solution: how about other async executors instead of tokio? Since we only need to spin and block in the Database trait, a minimal executor can be just endlessly calling poll until the requests are done. But I doubt alloy-transport compatibility here, especially ws backends.
The interpreter is very sensitive to these kinds of changes and VM work is not that small that I would be okay to put it in a async task.