Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

In all cases where we've deployed goliath, its running with a single thread. In theory, nothing stops you from creating a thread to do some background task (or EM.defer), but then you're on your own to make sure you have all the right synchronization logic.

As far as middleware goes, because you are reusing the same "app chain" between multiple requests, you just have to make sure that your middleware does not rely on any instance variables since those will get clobbered by other requests. Check the wiki page on middleware, we have a few examples around this.

Last but not least.. the EM reactor runs on a single core, so you're basically in the same deployment scenario as Thin or node.js. Having said that (always a caveat! ;)), Goliath can run on JRuby and Rubinius.. so in theory we have non-GILed environments there, which means we can start multiple reactors and run across multiple cores from within the same proc. This is not something I've experimented with in practice yet, but in theory its possible.



2011 is either going to suck or be awesome depending on how quickly the new Ruby 1.9 features are taken up by Rubinius and JRuby.

Having to choose between multiple threads and a better language is really not a decision you should have to make.


--1.9 mode works really well under JRuby now - that was a big push within 1.6 and they've made a lot of progress. I'd call it "almost there".

Rubinius is a little bit further behind, but I've been able to run our Goliath stack on it, and that exercises quiet a few syntactic changes. So, I think both are close.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: