Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
EventMachine -> concurrent-ruby, take two #23305
referenced this pull request
Jan 28, 2016
added a commit
this pull request
Jan 29, 2016
@TiagoCardoso1983 we're not using the block form of
I'm not sure what you're implying we should do differently here. Do you have a specific recommendation?
@matthewd the main reason eventmachine was removed is because it doesn't build under windows, right? I do prefer the implementation using nio4r, just wanted to state the windows potential issue while rails is still in beta mode so anyone with access to the environment could test it. Rails historically refrains from using dependencies with extensions so that it can "go where ruby goes". This contract has been broken once already with the html sanitizer gem. I'm afraid most of the tester pool will be using some *NIX form running against the libev reactor and will not test the fallback IO.select, so just wanted to state the potential drawback before the official release of 5.
seriously is there really anyone running production rails code under windows ? For development I can understand but I would be impressed otherwise. Eventmachine also has had bugs of its own for a while now althought development seems to now happens again on it after years of a mostly abandonned codebase with a laundry of pull requests ready to be merged with nobody to do it.
concurrent-ruby and nio4r seems like the best bet for me and a really good choice.
I'm not concerned about Windows production deployments either. The main use
On Thu, Feb 4, 2016 at 4:05 PM, Julien Ammous email@example.com
@schmurfy I don't think anyone wants to deploy action cable in production relying on IO.select, whatever the platform is :) Windows is still a relevant development environment, and is annoying mostly because a lot of dependencies go the "we only support UNIX" way.
Anyway, I can see this going the activejob/rails way in that one supports the basic setup for synch-jobs/webrick and then it's up for the developer to decide the production setup and dependencies. Main requirement for the basic setup is that it works well where ruby works.