Hacker News Reader

Comment by rajangdavis | Hacker News Reader

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.

View on HN

Yes, 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.

Awesome! Thanks for the article, can't wait to see this library progress!

So 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?

I 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.

Ruby's Global Interpreter Lock (GIL) is applicable, and not "sidestepped" with Async.

Reply on news.ycombinator.com