4 ms·
Shame on me for thinking that you needed other languages for good concurrency. This looks awesome!
by mattiemass 11y ago
Shame on me for thinking that you needed other languages for good concurrency. This looks awesome!
- xiaoma 11y agoThe GIL prevents parallelism but not concurrency.
- deleted 11y ago[deleted]
- keypusher 11y agoSo if I have 2 CPU-bound tasks, none of the tools in this toolbox will allow them to run in parallel on multiple cores?
- chrisseaton 11y agoNot if you use MRI, but they will if you use Rubinius or JRuby.
- vidarh 11y agoThey can't run in parallel while in the interpreter on MRI. Code that spends lot of time in the kernel (long running system calls for IO etc.) or in C extensions (say database adapters) can run properly in parallel, so on MRI it very much depends on your workload. If you want to ensure proper parallelism, then fork.
- s_kilk 11y agoCorrect, on MRI at least.
- est 11y agoIf you are even thinking about running CPU-intensive tasks in Python or Ruby, you are doing it wrong, it's not fast anyway.
- taf2 11y agoYep, in these cases use fork
- decentrality 11y agoUse Rubinius or jRuby and not MRI if you want to escape the GIL. If you use any concurrency approaches with a GIL in place, there will be only an appearance of parallelism.