3 ms·

I work on a large multi-threaded ruby code base and it's always a pain to deal with engineers introducing the async usage in it. Most of the time these engineer

I work on a large multi-threaded ruby code base and it's always a pain to deal with engineers introducing the async usage in it. Most of the time these engineers don't have a grasp on what fibers are good for and we have to painstakingly review their code and provide feedback that no, it's not magical concurrency, we have a limited number of fix sized connection pools for postgres, redis, memcache, etc available in the process and fibers have to respect those limits as much as threaded code. In fact it's better if you don't introduce any additional concurrency below the thread-per-request model if you can. Only in places like concurrent http calls do we allow some async/fiber usage but even then it ends up nominally looking like threaded code and the VM context switching time saved by using fibers instead of threads is trivial. Trying to use fibers instead of threads in typical CRUD workloads feels a little cargo culty to me. Fibers are cool and performant but usually they should be limited to lightweight work with large concurrency requirements.

Glyptodon 2y ago
I wish there were limited forms of true parallelism available with fibers instead of it just being another concurrency construct limited by an interpreter lock. I feel like there should be an in-language construct for stuff that's safely parallel and narrow, and not just Ractors. But I do get that it'd be a footgun for many.
- kubectl_h 2y ago
  I agree. I've thought about POCing some ractor usage for actual CPU bound workloads but ultimately it would be an academic exercise and most of our engineers aren't even thinking about the code performance on that level. My beef, if you will, with async (and I realize now I was a little loose in making the distinction between async and fibers) is that engineers reach for async because they are intimidated by threaded code. Instead they are used to the ergonomics of async/await in the browser and think it's basically the same with the async library in ruby and is somehow immune to the considerations you have to make when spawning a thread. This just isn't true. The dragons are mostly the same, or at least they are in our code base.

Glyptodon 2y ago

I wish there were limited forms of true parallelism available with fibers instead of it just being another concurrency construct limited by an interpreter lock. I feel like there should be an in-language construct for stuff that's safely parallel and narrow, and not just Ractors. But I do get that it'd be a footgun for many.

kubectl_h 2y ago
I agree. I've thought about POCing some ractor usage for actual CPU bound workloads but ultimately it would be an academic exercise and most of our engineers aren't even thinking about the code performance on that level. My beef, if you will, with async (and I realize now I was a little loose in making the distinction between async and fibers) is that engineers reach for async because they are intimidated by threaded code. Instead they are used to the ergonomics of async/await in the browser and think it's basically the same with the async library in ruby and is somehow immune to the considerations you have to make when spawning a thread. This just isn't true. The dragons are mostly the same, or at least they are in our code base.