3 ms·
>Because threads share the same memory space they have to be carefully coordinated to safely manage state. Ruby threads cannot run CPU-bound Ruby code in parall
by eduction 2y ago
>Because threads share the same memory space they have to be carefully coordinated to safely manage state. Ruby threads cannot run CPU-bound Ruby code in parallel, but they can parallelize for blocking operations
Ugh. I know Ruby (which I used to code in a lot more) has made some real progress toward enabling practical use of parallelism but this sounds still pretty awful.
Is there any effort to make sharing data across threads something that doesn't have to be so "carefully coordinated" (ala Clojure's atom/swap!, ref/dosync)?
Is the inability to parallelize CPU-bound code to do with some sort of GIL?
- vidarh 2y agoThat's what Ractor is for, if you want full parallelization without processes. And, yes, it's to do with a GIL/GVL. The lock is released during blocking IO, and some C extensions etc., so in practice for a lot of uses it's fine.
- sqeaky 2y agoThey ditched the GIL a while a ago. But there are smaller locks fighting for resources. EDIT - I remember when patch notes years ago said the GIL was gone and this says there is a GVL, I guess there is some subtle difference. then I think for practical purposes, "yes" is your answer, but not in precisely that name.
- Lio 2y agoIt all depends on your Ruby runtime. If you want parallel threads then you can use JRuby and your threads will run in parallel on the JVM. I've used the Concurrent-Ruby gem to coordinate that[1]. It has copies of some of the Clojure data structures. Otherwise, Ractors the up coming solution for MRI Ruby. 1. https://github.com/ruby-concurrency/concurrent-ruby https://github.com/ruby-concurrency/concurrent-ruby