As someone who spent 15+ years doing Ruby/Rails, it’s nice to see this land.
That said, these days you’ll pry the BEAM from my cold, dead hands. It’s hard to go back to any other concurrency story.
show comments
ramon156
So fibers are a lot like threads but they're more scoped to a task that can be paused and resumed, that's kinda cool
show comments
mrinterweb
This looks fantastic for a common async workflow I use. I often use one job to fan out multiple individual http request jobs. The reason I prefer jobs for this is easy and consistent retry logic, and durability. I want to make sure those HTTP requests eventually go through. Fibers would be much better suited for this. So much of work that goes onto work queues is IO bound, and fibers are a great fit for that.
QGQBGdeZREunxLe
Didn't EventMachine solve these types of issues way back when?
Is it possible to either have multiple ractors dispatching jobs with fibres or to set up multiple queues with different strategies?
E.g. one for IO bound and one for CPU bound?
With Sidekiq I’ve had luck having workers running on Truffleruby but generally don’t use it for my main rails apps.
show comments
jherdman
Has anyone played with this and SQLite? I have no data, just a hunch, but I’d think this is a recipe for corruption if you’re doing lots of writes.
show comments
swe_dima
My concern is number of database connections. In the example it's 100 fibers per worker, at that rate you are going to exhaust db connections sooner. Happy to be wrong.
As someone who spent 15+ years doing Ruby/Rails, it’s nice to see this land.
That said, these days you’ll pry the BEAM from my cold, dead hands. It’s hard to go back to any other concurrency story.
So fibers are a lot like threads but they're more scoped to a task that can be paused and resumed, that's kinda cool
This looks fantastic for a common async workflow I use. I often use one job to fan out multiple individual http request jobs. The reason I prefer jobs for this is easy and consistent retry logic, and durability. I want to make sure those HTTP requests eventually go through. Fibers would be much better suited for this. So much of work that goes onto work queues is IO bound, and fibers are a great fit for that.
Didn't EventMachine solve these types of issues way back when?
https://github.com/eventmachine/eventmachine
This is a nice update.
Is it possible to either have multiple ractors dispatching jobs with fibres or to set up multiple queues with different strategies?
E.g. one for IO bound and one for CPU bound?
With Sidekiq I’ve had luck having workers running on Truffleruby but generally don’t use it for my main rails apps.
Has anyone played with this and SQLite? I have no data, just a hunch, but I’d think this is a recipe for corruption if you’re doing lots of writes.
My concern is number of database connections. In the example it's 100 fibers per worker, at that rate you are going to exhaust db connections sooner. Happy to be wrong.