Description
Overview
Note
RFC; Still playing around w/ this while hooking up the engine actor
The kona-engine
crate currently exposes a few "task"s, which are spawned as background tasks w/ an accompanying communications handle. This pattern is nice in situations where we need to spawn many background tasks in parallel, and communicate with them while they process. However, for the sake of the engine, it creates complexity for the actor in the node service. Engine API operations in the Rollup Node must be sent in-order, and we should never have more than one operating in the background, removing the need for a more complex background task pattern.
Instead of the background task + async comms pattern, we can reduce boilerplate and complexity here by just exposing functions to perform the engine updates, i.e. what is currently in execute
for each of the tasks. Then, the actor can just dispatch the tasks and perform operations with their results, and not be locked into the multi-threaded communication model.
Old Usage
// Spins off a bg task w/ a `JoinHandle` + channels to communicate
let my_eng_task = MyEngineTaskExt::spawn(<input>);
// ...
// Now we have to set up an event loop just for this one operation to communicate with.
// Notice we're already blocking (asynchronously) on the loop anyways, while we wait for
// it to get finished - we have to in order to guarantee that engine operations to be applied
// in order.
loop {
select ! {
_ = my_eng_task.handle => { /* task exited */ }
msg = my_eng_task.receiver.recv() => { /* incoming message from task; Possibly needs response. */ }
}
}
New Usage
let res = my_eng_task(input).await?;
// .. do something with `res` ..
Metadata
Metadata
Assignees
Type
Projects
Status
Backlog