We’re working hard on improving multi-threading support in Crystal.
Current focus is on refactoring the event loop to use system selectors and lifetime subscriptions: New Event Loop (UNIX): call for reviews & tests) (RFC 7).
The multi-threaded scheduler implementation from RFC 2 is also pretty evolved and available as a standalone shard for testing: ysbaddaden/execution_context.
These efforts are the core components for multi-threading support and do most of the heavy lifting. But they won’t get us all the way there.
This thread is supposed to identify and collect that tasks needed for making multi-threading a prime-time feature, in an informal way.
Please note that this is a meta thread and not the place to discuss details of individual tasks. That should happen in the specific task discussions.
I’ll extend and edit the list following the discussion.
Once we have sufficiently identified the tasks, we’ll convert them into actionable items for the issue tracker.
Runtime:
- Thread-safety for union types (#15085)
ThreadLocalValueis not fiber-aware (#15088)- Ensuring
class_getterruns exactly once under concurrent access (#14905)
Stdlib:
- Evaluate the thread-safety of every stdlib component (for example,
XMLis known to not be thread-safe). Issues should be resolved or clearly documented. - Thread-safe implementations of generic data structures like
ArrayandHash. Details are to be determined. - Thread-safety for IO (IO can be duplicated in MT · Issue #8438 · crystal-lang/crystal · GitHub, puts in a multithreaded environment · Issue #8140 · crystal-lang/crystal · GitHub)
- Add more concurrency primitives (or promote existing ones to the public API: rwlock, semaphore, mutex etc.) (example: GitHub - ysbaddaden/syn: Synchronization primitives to build concurrent and parallel-safe data structures in Crystal)
Documentation:
- Lead an initiative to test and document the multi-threading capabilities in the ecosystem (i.e. shards).
- Generate learning materials on execution contexts and safe multi-threading in Crystal.
Infrastructure:
- Plan the transitioning process from current single-threaded scheduler (and optional
-Dpreview_mt) to execution contexts. - Enhance the CI matrix to test several runtime configurations on all supported platforms (especially during the transitioning process)
Related efforts:
These are not strictly required, but relevant side-quests.
- Ordered queue implementation for efficiently keeping track of timers in the event loop (performance)
- io_uring as system selector on Linux (performance)
aiofor async read/write over regular disk files withkqueueon *BSD and Darwin- Async DNS resolution (#13619)
- Consider moving other stuff on the event loop (e.g.
Process.wait(on Unix), OS signals) - Structured Concurrency