Ruby Fiber Scheduler(brunosutic.com)
brunosutic.com
Ruby Fiber Scheduler
https://brunosutic.com/blog/ruby-fiber-scheduler
17 comments
As part of my PhD I created a CSP implementation in Ruby: https://github.com/omegahm/emit Here I also created a Fiber scheduler, as well as CSP channels and processes.
Fiber Scheduler Interface feature was added to Ruby 3.0 in December 2020 https://docs.ruby-lang.org/en/3.0/Fiber/SchedulerInterface.h.... Yet, the latest commit in this repo is 3 years ago.
You probably implemented your own custom scheduler implementation, right?
You probably implemented your own custom scheduler implementation, right?
The examples in this article don't really do anything other than interact with the outside world in total isolation from each other. How does one declare dependencies between scheduled fibers and communicate shared data?
All the usual stuff is still available, so depending on what you need you could just use a `Queue` as the communication bus between several fibers. Anything wrapped in a Mutex would also work, since waiting for the lock is handled by the FiberScheduler.
That said I imagine that for most Ruby applications the real answer would be "you don't and you don't really need to". The most obvious killer applications for Fibers and FiberSchedulers seem to be web servers (most requests spend quite some time waiting for DB/API calls) and IO-intensive background jobs (also here, the majority of the time is spent waiting for some external server to respond). Fibers all get multiplexed on the same operating system thread anyway, so you don't really increase parallelism by communicating between individual fibers.
If you really wish to use multiple parallel threads in Ruby, Ractors are the way to go or otherwise C extensions that drop the GIL. That is outside the scope of Fibers though.
That said I imagine that for most Ruby applications the real answer would be "you don't and you don't really need to". The most obvious killer applications for Fibers and FiberSchedulers seem to be web servers (most requests spend quite some time waiting for DB/API calls) and IO-intensive background jobs (also here, the majority of the time is spent waiting for some external server to respond). Fibers all get multiplexed on the same operating system thread anyway, so you don't really increase parallelism by communicating between individual fibers.
If you really wish to use multiple parallel threads in Ruby, Ractors are the way to go or otherwise C extensions that drop the GIL. That is outside the scope of Fibers though.
For example use Queue, which (I guess) the scheduler knows about.
Thanks for an interesting article.
Just one nit-pick. Content on this page is really hard to read on big screens. This one line of css fixes this.
body { margin-left: calc(50vw - 280px); }
Just one nit-pick. Content on this page is really hard to read on big screens. This one line of css fixes this.
body { margin-left: calc(50vw - 280px); }
That just centers the column. It'll only make a meaningful difference if you maximize your browser window.
There's little point maximizing a browser on a big screen so I don't. My portal into the web page is roughly square, about as wide as my screen is high, maybe a little bit wider - no more than 4:3 and probably closer to 5:4.
I use a left-aligned tab tree and and other apps, such as console terminals and my note taking app to the left of the browser, to use the space left over.
Wide screen display of mostly text content doesn't make a whole lot of sense.
There's little point maximizing a browser on a big screen so I don't. My portal into the web page is roughly square, about as wide as my screen is high, maybe a little bit wider - no more than 4:3 and probably closer to 5:4.
I use a left-aligned tab tree and and other apps, such as console terminals and my note taking app to the left of the browser, to use the space left over.
Wide screen display of mostly text content doesn't make a whole lot of sense.
I have a 15" laptop screen and it was uncomfortable to read. Fortunately, reader mode worked.
I'll never get these type of minimalist websites that limit themselves to 80 chars like terminals BUT not center the content. When you have a big display, it's such a pain
Probably a bug. It's centered on mobile, but not on desktop. The code block textsize is also matching the regular textsize on mobile, while it's much too small on desktop. The mobile reading experience is smooth.
(tested with Chrome Android toggling desktop site)
(tested with Chrome Android toggling desktop site)
Disagree on the text being too small for desktop, and if it is CTRL+ZOOM is easy enough to do
Not sure why you felt the need to disagree here.
https://i.imgur.com/KHl2ko6.jpg
That's how it looks to me in desktop mode. Code textsize like half of normal textsize and linebreaks after sometimes just 1 word. That's hardly intentional styling and it looks completely fine in mobile mode.
https://i.imgur.com/KHl2ko6.jpg
That's how it looks to me in desktop mode. Code textsize like half of normal textsize and linebreaks after sometimes just 1 word. That's hardly intentional styling and it looks completely fine in mobile mode.
That screenshot looks like you're loading the desktop site on a phone. In this case I think that's triggering text auto resizing which has made the body text large but left the code text very small.
When looking at the site in mobile mode or desktop it does seem better. I do agree that many sites use font sizes that are too small these days though.
When looking at the site in mobile mode or desktop it does seem better. I do agree that many sites use font sizes that are too small these days though.
With Firefox on an actual desktop it looks fine, code fontsize matches text size
I felt the need to disagree because a lot of these "font is too small" complaints seem to be advocating for people using larger font sizes in general. Which I would prefer not to see, default font sizes are already large enough
I felt the need to disagree because a lot of these "font is too small" complaints seem to be advocating for people using larger font sizes in general. Which I would prefer not to see, default font sizes are already large enough
It's clearly going for a man page aesthetic, so it's unconventional but it gives the site a personality. I appreciate the line wrapping.
It's better than, say, Dan Luu's website or any other one that renounces CSS, so viewing it full screen on a large display turns paragraphs into single lines.
It's better than, say, Dan Luu's website or any other one that renounces CSS, so viewing it full screen on a large display turns paragraphs into single lines.
Valid complaint, I'll fix that. I'm on a 13 inch screen and didn't test it on a desktop-size screen.
I like it. It's easier to read across short lines quickly versus too long. That being said, you could probably get away with a little bit longer.