[HN Gopher] Ruby 3 adds Scheduler Interface for Fibers
       ___________________________________________________________________
        
       Ruby 3 adds Scheduler Interface for Fibers
        
       Author : ksec
       Score  : 74 points
       Date   : 2022-06-23 14:07 UTC (8 hours ago)
        
 (HTM) web link (blog.kiprosh.com)
 (TXT) w3m dump (blog.kiprosh.com)
        
       | brunosutic wrote:
       | I feel like the linked article is based heavily on my own article
       | on the same subject: https://brunosutic.com/blog/ruby-fiber-
       | scheduler
       | 
       | Too bad the article doesn't contain the source reference, but oh
       | well. I hope it gets the word out about this new cool stuff in
       | Ruby.
        
         | claudiug wrote:
         | it looks like the author read your article, then rewrote it a
         | bit, and make some noise, as is a us/indian shop
        
       | ptx wrote:
       | Can this be used for UI callbacks as well, like async/await in C#
       | and coroutines in Kotlin?
       | 
       | In other words, with an appropriate fiber scheduler, could I
       | start a function on the UI thread, suspend it while performing
       | some background operation and then resume the same function again
       | on the UI thread?
        
         | WJW wrote:
         | Yes, that is one of the use cases that it could be used for. It
         | does require of course that your UI library understands fibers,
         | and as I understand it most ruby UI libraries depend heavily on
         | C libraries that are not designed with Ruby fibers in mind.
        
           | [deleted]
        
       | dalyons wrote:
       | i think this announcement https://brunosutic.com/blog/async-ruby
       | & the associated async libraries
       | (https://github.com/socketry/async) do a much better job of
       | showing off the potential for the ruby 3.1+ fiber scheduler.
       | Async gem is powered by a fiber scheduler under the hood, and
       | what you get is un-colored async-ready ruby code.
       | 
       | That is to say, you can write a normal rack app with falcon-async
       | as the webserver and get node/event-loop scale co-operative
       | concurrency without changing your code. Its pretty exciting!
       | 
       | Unfortunately rails makes heavy use of thread locals which arent
       | compatible with fiber concurrency, so its going to take awhile
       | until its async-ready, but I believe progress is being made
       | (Async ActiveRecord was merged recently).
        
         | byroot wrote:
         | Active Record async queries have nothing to do with fibers, the
         | fiber scheduler or the `async` library.
         | 
         | As for the heavy use of thread locals, we introduced an
         | indirection to solve the problem. I can't say for sure every
         | thing is ironed out, but if people find other issues we'll fix
         | them.
         | 
         | That said, don't expect any performance gain running a typical
         | Rails app with falcon. Like NodeJS, It only makes sense if your
         | app is predominantly IO.
        
           | dalyons wrote:
           | sorry i should have been crisper in my language - there is
           | the new AR async queries (which as you correctly said is a
           | totally different thing). And then there is separately
           | fibered support in activerecord, which will allow the use of
           | the async library for co-op concurrency.
           | 
           | Yeah I dont expect single path performance gain, what i'm
           | hopeful for is more concurrency for the same memory across a
           | large pool of web workers in a high scale app. Thus saving a
           | bunch of $$$
           | 
           | EDIT: i just saw your other comment, i suppose you're right
           | w.r.t latencies, there may be less benefit to this than i
           | expected for a standard rails app.
        
           | endorphine wrote:
           | Isn't the typical Rails app IO-bound?
        
             | byroot wrote:
             | It very much isn't. Most well crafted Rails apps try to
             | minimize IOs inside web requests by deferring any long IO
             | into background job, and trying to optimize SQL queries.
             | 
             | At best you may find apps that are 50% IOs. That may seems
             | like a lot, but since you can only execute one fiber (or
             | thread) at a time (because there is a GVL), that means two
             | concurrent requests per process.
             | 
             | So in such scenario there isn't a lot of benefit in making
             | fibers your main execution primitive (each request get one
             | fiber). You'll save a handful of MB of RAM, but loose
             | thread preemption, meaning your latency will frequently be
             | impacted.
             | 
             | Doesn't mean fibers are useless though. You can still have
             | a mix of forking and threads, and then use fibers inside
             | your request cycle to query resources concurrently.
             | 
             | But fiber based servers are not really well suited for
             | hosting Rails apps. They're much more suited for extremely
             | IO heavy tasks, like proxies or bridge. e.g you subscribe
             | to Redis and forward events into a websocket, that sort of
             | things.
        
       ___________________________________________________________________
       (page generated 2022-06-23 23:01 UTC)