Swift 6.2 Concurrency Modernization Plan

[KrisSimon]

Summary

Analysis of ARO's concurrency patterns compared to Swift 6.2 best practices from the article "Mastering Swift 6.2 Concurrency".

Current State

The ARO codebase uses a hybrid async/await + NSLock model:

Pattern	Count	Notes
@unchecked Sendable classes	30+	Manual NSLock synchronization
Actors	1	Only RepositoryStorageActor
async/await occurrences	508	Primary concurrency mechanism
DispatchSemaphore usage	Multiple	For async-to-sync bridging
nonisolated(unsafe)	11	In C bridge code

Key Swift 6.2 Features We Could Adopt

Feature	Description	Benefit
Actors	Replace @unchecked Sendable + NSLock	Compile-time data race prevention
Actor isolation inheritance	#isolation parameter	Reduce executor hops, avoid reentrancy
@concurrent macro	Force method to run on GCE	Explicit background execution
nonisolated(nonsending)	Inherit caller's executor	Cleaner async patterns
async let	Structured parallel operations	Replace manual TaskGroup patterns

Proposed Changes

Phase 1: Convert Registries to Actors (Small effort)

Current pattern:

public final class ActionRegistry: @unchecked Sendable {
    private let lock = NSLock()
    private var actions: [String: any ActionImplementation.Type] = [:]
}

Proposed pattern:

public actor ActionRegistry {
    private var actions: [String: any ActionImplementation.Type] = [:]
}

Files:

• Sources/ARORuntime/Actions/ActionRegistry.swift
• Sources/ARORuntime/SystemObjects/SystemObjectRegistry.swift
• Sources/ARORuntime/Services/ServiceRegistry.swift

Phase 2: Convert EventBus to Actor (Medium effort)

Complex state management with 4 mutable collections currently protected by NSLock.

File: Sources/ARORuntime/Events/EventBus.swift

Phase 3: Convert RuntimeContext + GlobalSymbolStorage (Medium effort)

Hot path for variable binding/resolution - needs benchmarking.

Files:

• Sources/ARORuntime/Core/RuntimeContext.swift
• Sources/ARORuntime/Core/ExecutionEngine.swift (GlobalSymbolStorage)

Phase 4: Convert StatementScheduler (Medium effort)

Continuation management and futures system.

File: Sources/ARORuntime/Core/StatementScheduler.swift

Phase 5: Add Actor Isolation Inheritance (Small effort)

Use #isolation pattern to avoid unnecessary executor hops:

func fetchFromDisk(isolation: isolated (any Actor)? = #isolation) async {
    // Inherits caller's SerialExecutor - no suspension point
}

Phase 6: Refactor C Bridge (Large effort)

Current issues:

• nonisolated(unsafe) globals in RuntimeBridge.swift
• Mixed NSLock + nonisolated(unsafe) in ServiceBridge.swift
• DispatchSemaphore for sync-to-async bridging

Proposed approach:

1. Create dedicated bridge actors
2. Use assumeIsolated for C callbacks
3. Evaluate async-only API where possible

Files:

• Sources/AROCRuntime/RuntimeBridge.swift
• Sources/AROCRuntime/ServiceBridge.swift
• Sources/AROCRuntime/ActionBridge.swift

Phase 7-9: Additional Improvements (Small effort each)

• Add async let patterns for parallel operations
• Add @concurrent to CPU-intensive methods
• Fix EventLoopGroupManager lazy initialization race

Full Class Conversion List

Class	File	Current Pattern
ActionRegistry	Actions/ActionRegistry.swift:27	NSLock
SystemObjectRegistry	SystemObjects/SystemObjectRegistry.swift:41	NSLock
ExternalServiceRegistry	Services/ServiceRegistry.swift:102	NSLock
EventBus	Events/EventBus.swift:16	NSLock + continuations
RuntimeContext	Core/RuntimeContext.swift:12	NSLock
GlobalSymbolStorage	Core/ExecutionEngine.swift:724	NSLock
DependencyGraph	Core/DependencyGraph.swift:67	NSLock
StatementScheduler	Core/StatementScheduler.swift:124	NSLock + futures
StatementFuture	Core/StatementScheduler.swift:38	NSLock + continuations
EventLoopGroupManager	Core/EventLoopGroupManager.swift:15	NSLock + lazy
ShutdownCoordinator	Actions/BuiltIn/ServerActions.swift	NSLock + Semaphore

Benefits

1. Safety - Compile-time data race prevention instead of runtime locks
2. Maintainability - Cleaner code without manual lock management
3. Performance - Reduced lock contention on hot paths
4. Modernization - Align with Swift 6.2 best practices

Testing Strategy

1. Unit tests for actor isolation behavior
2. Integration tests with existing Examples/
3. Benchmarks comparing NSLock vs actor performance
4. Native compilation verification (aro build)

Discussion

Would love feedback on:

• Priority of phases
• Concerns about actor performance in hot paths
• C bridge architecture alternatives
• Any classes that should remain lock-based

[KrisSimon]

Cross-Platform Compatibility (macOS, Linux, Windows)

Will it work the same on all platforms?

Yes, with caveats. Swift actors and structured concurrency are fully cross-platform:

Feature	macOS	Linux	Windows
Swift Actors	✅ Full support	✅ Full support	✅ Full support
async/await	✅	✅	✅
TaskGroups	✅	✅	✅
#isolation	✅	✅	✅
@concurrent	✅	✅	✅

Current NSLock-based code also works cross-platform via Foundation/swift-corelibs-foundation, so we're essentially replacing one cross-platform solution with another.

Platform-Specific Considerations

1. Linux: Swift concurrency uses a cooperative thread pool. Behavior should be identical to macOS.

2. Windows: Swift concurrency is supported but the ecosystem is younger. We should ensure CI runs Windows tests.

3. C Bridge (Native Compilation): The @_cdecl functions and DispatchSemaphore patterns work cross-platform, but assumeIsolated behavior should be verified on each platform.

---

Risks of This Refactoring

High Risk

Risk	Impact	Likelihood
API Breaking Changes	All callers of registry/context methods need await	High
C Bridge Breakage	Native compilation (aro build) could fail	Medium
Behavioral Changes	Actor reentrancy differs from lock serialization	Medium

Medium Risk

Risk	Impact	Likelihood
Performance Regression	Actor overhead on hot paths (RuntimeContext)	Medium
Deadlock During Transition	Mixing sync/async incorrectly	Medium
Test Coverage Gaps	Race conditions may not surface in tests	Medium

Low Risk

Risk	Impact	Likelihood
Platform-Specific Bugs	Different behavior on Linux/Windows	Low
Memory Overhead	Actors have slightly higher memory footprint	Low

---

Risk Mitigation Strategies

1. Incremental Rollout with Feature Flags

// Temporary toggle during migration
enum ConcurrencyMode {
    case legacy  // NSLock-based
    case modern  // Actor-based
}

let concurrencyMode: ConcurrencyMode = .modern

This allows quick rollback if issues arise.

2. Parallel Implementation Strategy

Keep both implementations during transition:

// Old: Keep as internal
final class ActionRegistryLegacy: @unchecked Sendable { ... }

// New: Public API
public actor ActionRegistry { ... }

Run both in tests, compare results.

3. Comprehensive Benchmarking

Before each phase, establish baselines:

// Benchmark hot paths
measure {
    for _ in 0..<10000 {
        context.bind("key", value: "value")
        _ = context.resolve("key")
    }
}

Reject changes that regress by >10%.

4. Platform-Specific CI Matrix

Ensure every PR runs tests on:

• macOS (arm64, x86_64)
• Linux (Ubuntu 22.04, 24.04)
• Windows (if applicable)

5. C Bridge Isolation

Keep the C bridge as a separate phase (Phase 6). Don't touch it until the runtime refactor is stable.

6. Actor Reentrancy Audit

Document every await point in actor methods. Actor reentrancy can cause subtle bugs:

actor EventBus {
    func publish(_ event: Event) async {
        // DANGER: State could change during await
        let count = subscriptions.count
        await notifySubscribers(event)  // ⚠️ Suspension point
        // subscriptions.count might differ now!
    }
}

Mitigate with:

• Capture state before await
• Use withTaskGroup for atomic operations
• Add assertions for invariants

---

When Is the Best Time for This Refactoring?

Ideal Timing

1. After a major release - Clean slate, no pending features blocked

2. Before new features that touch affected components - Avoids refactoring new code twice

3. When CI/CD is stable on all platforms - Need confidence in cross-platform testing

4. During a "stabilization sprint" - Dedicated time for infrastructure work

Not Ideal Timing

1. During active feature development on EventBus, RuntimeContext, etc.

2. Before a deadline - Risk of regressions under time pressure

3. When platform support is incomplete - Need all targets in CI

Recommended Approach

Phase	When	Duration
Phase 1 (Registries)	Anytime - low risk	1-2 days
Phase 2 (EventBus)	After stabilizing Phase 1	2-3 days
Phase 3 (RuntimeContext)	After benchmarking Phase 2	3-4 days
Phase 4-5	After all tests pass	2-3 days
Phase 6 (C Bridge)	After interpreter refactor is stable	1 week
Phase 7-9	Opportunistic	As needed

Suggested Timeline

Start with Phase 1 (Registries) as a low-risk pilot:

• Minimal API surface
• Rarely in hot paths
• Easy to benchmark
• Good learning experience for the team

If Phase 1 succeeds without issues, proceed with confidence. If problems arise, the scope is contained.

---

Summary

Question	Answer
Will it work on Linux/Windows?	Yes, Swift concurrency is cross-platform
Will it work "the same but better"?	Mostly - compile-time safety instead of runtime locks
Main risks?	API breaks, performance regression, C bridge issues
How to minimize risks?	Incremental rollout, benchmarks, feature flags, platform CI
Best time?	After a release, before new features, with stable CI

The refactoring is worthwhile but should be approached methodically. Start small, measure everything, and keep rollback options available.