The cluster system was written before swift structured concurrency was introduced and actually uses its own concurrency runtime. That works fine, but adds some complexity and introduces problems for further development—one must keep two concepts in mind and provide ways to glue them together. Not to mention keeping dedicated concurrency parts and having to deal with two simultaneously is less scalable.
Natural solution for that is to move library to structured concurrency. There are two possible ways to start this migration:
- Remove old concurrency runtime step by step, class by class, and replace it with new structure concurrency.
- Rewrite system from scratch and use structured concurrency directly.
First way seems safe, but not straightforward—even though old actor references and behavior related files are marked as deprecated, system is built on top of those abstractions. So touching any of them leads to massive chain of changes.
Second seems massive and breaking, but actually way more straightforward—we already have clear picture of the system, and just need to rewrite/refactor to desired state. This will also give opportunity to refactor related repositories (e.g. swift-cluster-membership) with cleaner APIs.
After talking with @ktoso he proposed going full rewrite way with following steps:
Note that this is all high level, so each step could be clarified if needed. Also, even though all steps are high level—this is all part of one big refactor, so careful approach should be considered for refactoring and submitting PRs.
The cluster system was written before swift structured concurrency was introduced and actually uses its own concurrency runtime. That works fine, but adds some complexity and introduces problems for further development—one must keep two concepts in mind and provide ways to glue them together. Not to mention keeping dedicated concurrency parts and having to deal with two simultaneously is less scalable.
Natural solution for that is to move library to structured concurrency. There are two possible ways to start this migration:
First way seems safe, but not straightforward—even though old actor references and behavior related files are marked as deprecated, system is built on top of those abstractions. So touching any of them leads to massive chain of changes.
Second seems massive and breaking, but actually way more straightforward—we already have clear picture of the system, and just need to rewrite/refactor to desired state. This will also give opportunity to refactor related repositories (e.g. swift-cluster-membership) with cleaner APIs.
After talking with @ktoso he proposed going full rewrite way with following steps:
Note that this is all high level, so each step could be clarified if needed. Also, even though all steps are high level—this is all part of one big refactor, so careful approach should be considered for refactoring and submitting PRs.