...
- LibAries: library threading models and synchronicity
- Resolver and wallet might have different needs than other API functions.
Current design in Indy was implemented as part of IS-660
HIPE: https://github.com/hyperledger/indy-hipe/tree/master/text/0012-concurrency-improvement
- Mike's concerns: https://docs.google.com/document/d/1-oabbR7n4MsLsU-MGfrwbjJvB1V4nMroW_oh2BvYVXc/edit
- VON Anchor takes a significantly different approach:
- https://von-anchor.readthedocs.io/en/latest/von_anchor/anchors.html#revregbuilder
- "Neither multithreading nor green-threading primitives pass through the wrapper/shared-library barrier; subprocessing must occur early in the game before libindy sets up its dispatcher, as it operates in a separate thread(? message loop? it's been a while) that does not replicate over a fork (this is unix architecture not indy).
"In von_anchor, An external rev reg builder process uses file system semaphores as IPC, increases rev reg size as it scales up, and anticipates one rev reg in the future so that the issuer process never waits for a rev reg build."
- Other LibAries architecture suggestions
...