> you can think of it as "threads with none of the downsides"
And likely no actual parallel execution of Ruby code. I suppose fibers are scheduled for later when they perform I/O. Just like how C extensions release the interpreter lock before some expensive function, allowing other Ruby code to run in concurrently.
I thought so... Threads and processes are still in use. While yielding control on system calls is a great idea, it's a bit innacurate to say it's just like threads with none of the downsides. The upsides are missing too. Only the system calls are running in parallel here. The Ruby code remains single-threaded.
Still, much better than languages that lack schedulers where people are tricked into writing cooperatively scheduled code without even realizing it.
In MRI (aka "CRuby", standard ruby), you don't get parallelism with threads either, due to the GIL. (Similar to CPython).
A lot of people are used to thinking mostly of that scenario, where ruby doesn't currently give you parallism for threads either.
JRuby does give you parellism for threads -- but I believe currently doesn't actually implement true coroutines (Fibers are just implemented on top of threads), so there are now two reasons this wouldn't be as useful on JRuby, true.
And likely no actual parallel execution of Ruby code. I suppose fibers are scheduled for later when they perform I/O. Just like how C extensions release the interpreter lock before some expensive function, allowing other Ruby code to run in concurrently.