# Crystal multithreading support **URL:** \ **Category:** Crystal Contrib\ **Created:** [February 20, 2024, 4:55pm UTC](https://forum.crystal-lang.org/t/crystal-multithreading-support/6622 "2024-02-20T16:55:21Z")\ **Posts on this page:** 1\ **Showing post:** 19
**Author:** ![ysbaddaden](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.crystal-lang.org/ysbaddaden/32/2252_2.png) [@ysbaddaden](https://forum.crystal-lang.org/u/ysbaddaden)\ **Post date:** [February 23, 2024, 9:26am UTC](https://forum.crystal-lang.org/t/crystal-multithreading-support/6622/19 "2024-02-23T09:26:14Z")
Thanks for the feedback. We did study other languages. A lot! The concurrency model has been heavily influenced by Go (CSP). We’ve since been leaning to structured concurrency, though I prefer Erlang OTP for structuring applications (I prefer supervisors over nurseries). The parallelism implementation is solid as in “it’s stable”: it’s safe and can be used in production. Yet, it’s not as performant as it could. It certainly won’t keep all those cores at 100%. This is what the proposal in RFC 0002 aims to fix: push the implementation further (i.e. even closer to Go’s MT model) + give back some thread-level control (i.e. Kotlin’s execution contexts). Thanks for the language benchmarks. I see Crystal doesn’t have any MT implementations. I’ll fix that when I’ll start to have the new schedulers running (I only have a rough implementation right now that’s far from just compiling). --- _[View the full topic](https://forum.crystal-lang.org/t/crystal-multithreading-support/6622)._