Abstract
Usage of asynchronous Rust gives Iroha as a highly I/O bounded application greats benefits in usage of system resources.
At the same time when we have more asynchronous tasks ready to be executed then workers able to execute them, we may have undesirable issues and potential violation of SLA.
On the start of the project we made a decision to use `futures` API directly, while having `async-std` only as a runtime. While project matures we are ready to make a final decision and start using runtime API directly, still do not forcing clients to do so.
Async-std looks like a better choice in terms of support, simplicity and alignment with our needs.
Introduction
Working with `client_add_asset_quantity_to_existing_asset_should_increase_asset_amount_on_another_peer` test we found that time to propagate block between peers is unpredictable while usage of resources suffer from `loop` and `thread::sleep` inside asynchronous tasks.
Methods and Materials
We already have benchmarks for the solution based on `futures` API (Mutex, ThreadPool, etc) and interest for usage of `async-std` API (indirect Pools, Multiple Producers Multiple Consumers, RwLocks).
Threads Pooling
Because `async-std` hides tasks scheduling across workers inside it's internals (https://docs.rs/async-std/1.5.0/src/async_std/task/executor/pool.rs.html#27) we assume that our code will be cleaner without direct usage and passing of ThreadPool clones:
7 pub struct Torii {
8 url: String,
9 pool_ref: ThreadPool,
10 world_state_view: Arc<Mutex<WorldStateView>>,
11 transaction_sender: Arc<Mutex<TransactionSender>>,
12 message_sender: Arc<Mutex<MessageSender>>,
13 }
...
37 let state = ToriiState {
38 pool: self.pool_ref.clone(),
...
Using https://docs.rs/async-std/1.5.0/async_std/task/fn.spawn.html instead: `task::spawn(async {`
Channels
`futures` API provides only MPSC channels, while `async-std` can give us MPMC channels: https://docs.rs/async-std/1.5.0/async_std/sync/fn.channel.html
Locks
While `futures` provide Mutex, `async-std` gives an ability to use ReadWriteLock
Results
The only way to check performance impact is to rewrite code and compare benchmarks.