3 ms·
It looks like from a brief glimpse into the source code that the library is using Ruby Fiber's under the hood instead of Threads. From my limited understanding
by rajangdavis 5y ago
It looks like from a brief glimpse into the source code that the library is using Ruby Fiber's under the hood instead of Threads.
From my limited understanding, the programmer has to be explicit about starting and resuming the work within a Fiber as opposed to the Ruby VM.
- brunosutic 5y agoYes, async is using fibers as a concurrency primitive. Async gem is starting fibers automatically. Fiber pausing and resuming is handled by event reactor (also called "event loop") from 'nio4r' gem. io_uring support with asynchronous File IO is also on the way.
- rajangdavis 5y agoAwesome! Thanks for the article, can't wait to see this library progress!
- Toutouxc 5y agoSo the Async gem allows the programmer to fire "tasks" and wait for them to finish (the same way we can fire threads), but instead of OS-level threads (which is what MRI uses for Threads) it uses a new kind of Fibers, called "non-blocking Fibers", that are lightweight and don't use OS threads, like normal Fibers, but unlike normal Fibers they yield automatically to the scheduler when blocked (sort of like threads). Is this a correct-ish way to describe the current state of affairs?
- brunosutic 5y agoI think you're generally on the right track. Small correction: fibers (blocking or non-blocking) never used threads in any way. Fibers are "stackful coroutines", another concurrency primitive. They're pretty hard to understand, and unfortunately I can't find a good explanation of "Ruby Fibers" that I can link to.
- brunosutic 5y agoRuby's Global Interpreter Lock (GIL) is applicable, and not "sidestepped" with Async.