5 ms·

I haven't touched Ruby in a while, but are there any common multithreaded use cases? It seemed like the direction was to go multi-process for web workloads (E.g

I haven't touched Ruby in a while, but are there any common multithreaded use cases? It seemed like the direction was to go multi-process for web workloads (E.g. with Unicorn).

thibaut_barrere 6y ago
Both Puma (https://github.com/puma/puma https://github.com/puma/puma, a popular server these days) and Passenger Enterprise (paid) provide multithreaded web support. Also on the background jobs side, Sidekiq https://sidekiq.org https://sidekiq.org is very popular.
- deleted 6y ago
  [deleted]
ioquatix 6y ago
Those are both solid choices for servers. However neither of them have a scalability model suitable for HTTP/2 or WebSockets. That's something I wanted to try and address.
- nitrogen 6y ago
  I used EventMachine a lot about 8-10 years ago. I'm excited to see Ruby getting some concurrency love again. What are the goals and improvements of your underlying design in general, and especially those that make HTTP2 and WebSockets work?
  - ioquatix 6y ago
    Light weight event driven tasks are very important. I outline some of the key improvements in this talk: https://www.youtube.com/watch?v=Dtn9Uudw4Mo https://www.youtube.com/watch?v=Dtn9Uudw4Mo
- timdorr 6y ago
  And thank you for addressing it, Samuel! I converted the streaming and Autopark clients in the Tesla API gem from EM to Async and has been great: https://github.com/timdorr/tesla-api/blob/master/lib/tesla_api/stream.rb https://github.com/timdorr/tesla-api/blob/master/lib/tesla_a... No more globals, which makes it much safer to use inside of threaded job runners like Sidekiq.
  - ioquatix 6y ago
    It would be awesome to talk about your work in a blog post, do you think you can reach out to me to explain your work in more detail?
pizza234 6y ago
Not a common use case, but a GUI with background processing is terrible without parallelization. Even if the background process is I/O intensive (which is supposed to be most of the time waiting, therefore freeing the CPU for the foreground process), it doesn't mean it won't end up still blocking (I've experienced this with filesystem operations).
- ioquatix 6y ago
  Actually, I was looking at how audio loops work, and it seems like the low context switching overhead of fibers could be really great for stacks of effects and filters. Because the overhead is very small and predictable, and the ergonomics of fibers is easier to deal with, it could make for a really nice interface.
ken 6y ago
Concurrency is one of those core features which is hard to add after-the-fact, and so the initial design strongly determines the course of the language's life. It requires re-opening such fundamentals as what does it mean to call a function, or assign to a variable. "Nobody is using Ruby for multithreading" is both cause and effect. That's why I'm not terribly optimistic about projects like this (or the proposed Swift 6). That's not how these things work. Can you imagine a language which features good concurrency support today (like Erlang or Clojure) having been launched without it, and then announcing 5 (or 25) years later "We're going to address concurrency now"?
- ioquatix 6y ago
  Completely agree with you and to me that's why it's an exciting challenge. I'm not expecting to solve every problem, but I'm trying to carve out a solution which I think works for these legacy issues. Even if we didn't have a solution for the last 25 years, no harm in adding one now! :)

I haven't touched Ruby in a while, but are there any common multithreaded use cases? It seemed like the direction was to go multi-process for web workloads (E.g. with Unicorn).

thibaut_barrere 6y ago

Both Puma (https://github.com/puma/puma https://github.com/puma/puma, a popular server these days) and Passenger Enterprise (paid) provide multithreaded web support. Also on the background jobs side, Sidekiq https://sidekiq.org https://sidekiq.org is very popular.

deleted 6y ago
[deleted]

ioquatix 6y ago

Those are both solid choices for servers. However neither of them have a scalability model suitable for HTTP/2 or WebSockets. That's something I wanted to try and address.

nitrogen 6y ago
I used EventMachine a lot about 8-10 years ago. I'm excited to see Ruby getting some concurrency love again. What are the goals and improvements of your underlying design in general, and especially those that make HTTP2 and WebSockets work?
- ioquatix 6y ago
  Light weight event driven tasks are very important. I outline some of the key improvements in this talk: https://www.youtube.com/watch?v=Dtn9Uudw4Mo https://www.youtube.com/watch?v=Dtn9Uudw4Mo
timdorr 6y ago
And thank you for addressing it, Samuel! I converted the streaming and Autopark clients in the Tesla API gem from EM to Async and has been great: https://github.com/timdorr/tesla-api/blob/master/lib/tesla_api/stream.rb https://github.com/timdorr/tesla-api/blob/master/lib/tesla_a... No more globals, which makes it much safer to use inside of threaded job runners like Sidekiq.
- ioquatix 6y ago
  It would be awesome to talk about your work in a blog post, do you think you can reach out to me to explain your work in more detail?

pizza234 6y ago

Not a common use case, but a GUI with background processing is terrible without parallelization. Even if the background process is I/O intensive (which is supposed to be most of the time waiting, therefore freeing the CPU for the foreground process), it doesn't mean it won't end up still blocking (I've experienced this with filesystem operations).

ioquatix 6y ago
Actually, I was looking at how audio loops work, and it seems like the low context switching overhead of fibers could be really great for stacks of effects and filters. Because the overhead is very small and predictable, and the ergonomics of fibers is easier to deal with, it could make for a really nice interface.

ken 6y ago

Concurrency is one of those core features which is hard to add after-the-fact, and so the initial design strongly determines the course of the language's life. It requires re-opening such fundamentals as what does it mean to call a function, or assign to a variable. "Nobody is using Ruby for multithreading" is both cause and effect. That's why I'm not terribly optimistic about projects like this (or the proposed Swift 6). That's not how these things work. Can you imagine a language which features good concurrency support today (like Erlang or Clojure) having been launched without it, and then announcing 5 (or 25) years later "We're going to address concurrency now"?

ioquatix 6y ago
Completely agree with you and to me that's why it's an exciting challenge. I'm not expecting to solve every problem, but I'm trying to carve out a solution which I think works for these legacy issues. Even if we didn't have a solution for the last 25 years, no harm in adding one now! :)