<- Back
Comments (37)
- symfoniqAs 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.
- QGQBGdeZREunxLeDidn't EventMachine solve these types of issues way back when?https://github.com/eventmachine/eventmachine
- ramon156So fibers are a lot like threads but they're more scoped to a task that can be paused and resumed, that's kinda cool
- mrinterwebThis 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.
- LioThis 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.
- jherdmanHas 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.
- swe_dimaMy 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.
- nicechianti[dead]