Post

@intertwingly.net How can I learn more about any roadblocks to Sidekiq support in Roundhouse? Giving people the potential to choose their app runtime is super intriguing, removing the GVL for Sidekiq job execution is a massive scalability improvement for CRuby users.

No roadblocks, just things yet to be implemented. Current status: Sidekiq is recognized but not really supported. And there are a lot of interesting design discussions. For example, with Campfire, perform_later can be executed in the same process with no Solid Queue or Redis.

Sure, you can specialize Active Job execution, but I'm speaking of support for Sidekiq::Job users who are not using Rails at all. What needs to be implemented to support alternate Ruby app frameworks and daemons, like Roda, Sinatra or Sidekiq? I'd love to understand more, any docs?

In a nutshell, Roundhouse treats Rails (and associated ecosystem) as a programming language rather than a framework, and compiles it. github.com/oripekelman/... is a Sinatra inspired framework. I'm not aware of any Roda equivalent.

I gather that I didn't answer your question, so lets start over. Asking the author a Rails compiler how to support non-Rails usages of Sidekiq is not the right place to start. The right place to start is by understanding that Spinel is a subset of Ruby and if you conform to that subset you can...

I think you answered it, I’m still trying to wrap my head around the changing ecosystem so I had nothing to add. Ty!

Feel free to follow up with more questions, but some things to think about meanwhile: Spinel doesn't have a GVL but it does have a stop the world GC; this means that either real processes or ractors may be crucial to the design.

I’m not worried about GC at all, that’s something that will get better over time. The CRuby GVL is forever and Ractors are really, really hard to use for existing apps so Spinel seems like an interesting direction.