Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
AlexRamRam opened this issue Oct 5, 2023 · 0 comments
Labels
difficulty/03-medium Likely to take a couple of weeks; best accomplished by multiple contributors enhancement/refactor Improves flexibility/maintainability topic/architecture

Comments

@AlexRamRam
Copy link
Contributor

AlexRamRam commented Oct 5, 2023

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?

@AlexRamRam AlexRamRam added topic/architecture enhancement/refactor Improves flexibility/maintainability labels Oct 5, 2023
@HalosGhost HalosGhost added the difficulty/03-medium Likely to take a couple of weeks; best accomplished by multiple contributors label Mar 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
difficulty/03-medium Likely to take a couple of weeks; best accomplished by multiple contributors enhancement/refactor Improves flexibility/maintainability topic/architecture
Projects
None yet
Development

No branches or pull requests

2 participants