Async-std API usage

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

Usage of async-std with the same code does not affect the performance. So we decided to move onto async-std to get other benefits.

Page tree