brunosutic

7 ms·

31.
by brunosutic 4y ago
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
32.
by brunosutic 5y ago
Valid complaint, I'll fix that. I'm on a 13 inch screen and didn't test it on a desktop-size screen.
33.
by brunosutic 5y ago
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 imple
34.
Ruby Fiber Scheduler(brunosutic.com)
109 points by brunosutic 5y ago|17 comments
35.
Ruby Fiber Scheduler(brunosutic.com)
5 points by brunosutic 5y ago|0 comments
36.
Ask HN: Why is custom stripe integration so hard?
1 points by brunosutic 5y ago|1 comments
37.
by brunosutic 5y ago
The app is down right now. I'm getting 502 errors
38.
by brunosutic 5y ago
Red-black tree, a well-known algorithm also uses color references https://en.wikipedia.org/wiki/Red–black_tree
39.
by brunosutic 5y ago
Thank you for sharing your perspective in a non-conflicting way Yoric. It seems you have more experience than me with async-related work. I'll keep an eye on this kind of scenario you brought up.
40.
by brunosutic 5y ago
Wrap the example in a `Sync` block to get deterministic results. Now you don't have to worry if the code gets nested in an existing event loop. Sync do results = [] Async do sleep 10 results << &
41.
by brunosutic 5y ago
Thank you for the clarification. You are right, these types of race conditions are possible with Async Ruby. I find these races relatively easy to spot: yes, global state CAN change when you yield back to the reactor. IMO thread race condit
42.
by brunosutic 5y ago
> Does it come down to fundamental language differences? No, I don't think there's anything fundamentally different. Ruby 3.0 implements a "fiber scheduler" feature that enables "colorless Async". Fiber sche
43.
by brunosutic 5y ago
That's right - Async Ruby uses fibers (stackful coroutines) as a concurrency primitive. There's a lot to say about this, but the end result is that we get to write simple synchronous code and it can run asynchronously.
44.
by brunosutic 5y ago
I just ran your example and I'm getting `puts results` line to output "Hello", just as the program intends. I'm not sure why you're getting a different result. In any case, I'm assuring you: getting the results
45.
by brunosutic 5y ago
Async has async-websocket gem. I don't have experience with it so can't tell how it compares to ActionCable. https://github.com/socketry/async-websocket
46.
by brunosutic 5y ago
> Which means that you can just write a whole normal Ruby program, that just uses Task::Async.current.async(...) > All without having to pass the current task down the call stack everywhere. Yes, you can also use `Async { work }` inst
47.
by brunosutic 5y ago
Polyphony monkey-patches Ruby core methods... this has always prevented me from experimenting more with it. Source link: https://digital-fabric.github.io/polyphony/faq/#why-does-pol... > Polyphony “patches” som
48.
by brunosutic 5y ago
> I regret that this is generally false. Once you have async, you have race conditions and reentrancy issues Can you get more specific please? My experience is 100% from Ruby where I've worked heavily with threads in the past, and w
49.
by brunosutic 5y ago
Yes, this is possible! In fact this is a perfect use case for Falcon + Async.
50.
by brunosutic 5y ago
> Task counts themselves are also a pretty useless metric. Sure, you can have may fibers doing nothing. Sorry if I wasn't explicit. I was talking about tasks/fibers performing actual work, like handling HTTP connections. It&#x2
51.
by brunosutic 5y ago
> is it hard to get the results back out It's trivially easy to get the results, here's a quick example: require "async" require "open-uri" results = [] Async do |task| task.async d
52.
by brunosutic 5y ago
> What does Async (Fibers underneath) do differently than normal Threads? There's a lot to say on this topic. - Threads implement "preemptive scheduling". A scheduler switches control from one thread to another every 10ms
53.
by brunosutic 5y ago
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 un
54.
by brunosutic 5y ago
> the gem changed ownership I think the gem did change ownership at some point. The first couple gem releases from 2013 were yanked.
55.
by brunosutic 5y ago
Ruby's Global Interpreter Lock (GIL) is applicable, and not "sidestepped" with Async.
56.
by brunosutic 5y ago
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
57.
by brunosutic 5y ago
> This gem is almost a decade old Hm, the first commit to the gem was in 2017. The gem was not "advertised" so that the interfaces can be polished and done right. Async gem is hugely improved with Ruby 3.0 release (from Decem
58.
by brunosutic 5y ago
- Async Ruby is much more performant than threads. There are less context switches, enabled by the event reactor. The performance benefits are visible in simple scenarios like making a thousand HTTP requests. - Async is more scalable, can h
59.
by brunosutic 5y ago
Async Ruby is colorless! It's obvious from the examples provided in the post. For example, you can use the method `URI.open` both synchronously and asynchronously. It's something I didn't want to mention in the article becaus
60.
by brunosutic 5y ago
Yea, it's a big new Ruby feature. From what I was able to tell (I followed the discussion around this) enabling Rails to work with Async is not huge amount of effort. One guy was working on this, but he got distracted with other stuff.

More ›