mit-dci / opencbdc-tx

A transaction processor for a hypothetical, general-purpose, central bank digital currency

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Investigate alternatives to deeply nested callbacks (particularly in PArSEC) to improve code readability

AlexRamRam opened this issue · comments

In contrast to the Atomizer/2PC architectures, PArSEC requires a more standard form of the two-phase locking protocol where locks are sequentially accumulated as execution proceeds. As a result, the reader encounters deeper levels of nesting of callbacks in the PArSEC code base as they follow the flow of execution.

Using nested callbacks is sensible and efficient (avoids waiting or polling for tasks synchronously). However, the code becomes more difficult to follow, particularly for those with less experience with asynchchronous programming. This issue item asks the openCBDC community to investigate alternatives that aim to improve code readability without sacrificing performance.

One path is to use chain-able/continuable futures, which is not yet part of the C++ standard. This would allow us to chain asynchronous tasks, and might look like the following (ignoring parameterization of return values , inputs and other important details):

auto runTransaction = async( lockAddress() )
.then( lockTransactionID() )
.then( lockTicketID() )
.then ...

Until the c++ standard catches up, are there implementations of concurrency frameworks available today that help improve readability (without adding performance burdens) that also pass the necessary set of standards for openCBDC?. For example, I've experimented with one implementation here: https://github.com/Amanieu/asyncplusplus

Are there other solutions (i.e. a different threading model) that improves code readability without adding performance burdens?