rust - How to implement background thread in Substrate?

Question

Let's imagine I want to design a system similar to crowdfunding or to the auction. There is a fixed period of time for which such an event is running. Can I start a background thread that will periodically check whether the end time if the event has been reached and subsequently closes that event? I was looking into the futures crate (and some others) but is it usable within the Substrate? Is there any best practice on how to handle such scenarios?

question from:https://stackoverflow.com/questions/65660302/how-to-implement-background-thread-in-substrate

Answer 1

I believe the answer to futures is no. Here's more explanation:

I think it is better to think about what programming primitives are available inside a Substrate runtime, instead of trying to use a concept from general purpose programming (future) and try and re-purpose it for the Substrate runtime (top-down vs. bottom-up viewpoint).

So, let's think about the lifecycle of a runtime and see what makes sense there:

Inside a runtime, you are kinda stuck in a box. A (wasm) runtime code is spawned and executed by the (always native) client whenever a new block is there to be imported (or authored, but let's assume just importing for now), and killed and set aside afterwards (at least from the perspective of the runtime -- the client has runtime caching). My point being, anything that you don't commit to state (i.e. write in storage) at the end of the execution of each block is lost. This includes all the local variables, stack, heap, and anything else. So even if you were to use a future to spawn a task, that doesn't really fit into the programming model of Substrate runtimes, because even if that future lived in the runtime, as soon as the block is done, the wasm instance is dead and so is the future.

That is all ignoring the fact that you can only use crates that support no_std in the runtime, so not every async library will be available anyhow.

---

The main solution, as I hinted, is probably something that uses state storage to record the starting point of the auction, so that x blocks later you can still know when you started it, and if some threshold is passed, then you can finish your auction. You could use either a timestamp or a number of blocks for your duration of auction. Something along the lines of:

trait Config: frame_system::Config {
    // duration in time or block number
    type AuctionDuration<T::BlockNumber>;
}

// inside your on_initialize
fn on_initialize(n: T::BlockNumber) {
    if n % T::AuctionDuration::get() == 0 {
        // ^^^^^ note: ensure this is non-zero, else panic in runtime might happen. 
        // time to close the auction.
    }
}