Ruby 3 adds Scheduler Interface for Fibers
blog.kiprosh.com
blog.kiprosh.com
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.
I don't understand this part of the sentence. Was a word accidentally deleted?
So basically this is SEO spam, with a side of plagiarism or vice versa
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).
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.
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.
What is the rest 50% typically?
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.
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?