Solid Queue 1.6.0 now supports fiber workers (github.com)

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.

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

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.

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.

[dead]

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