EventMachine -> concurrent-ruby, take two #23305
Conversation
matthewd
force-pushed
the
concurrent-take-2
branch
from
8627936
to
c064355
Compare
|
Tested with Basecamp 👍 |
|
So feel free to merge. |
They're all at risk of races on the first requests.
Also, address the possibility of the listen thread dying and needing to be respawned. As a bonus, we now defer construction of the thread until we are first given something to monitor.
We may still try to send to it.
matthewd
force-pushed
the
concurrent-take-2
branch
from
0a55271
to
4d01cd1
Compare
EventMachine -> concurrent-ruby, take two
|
@matthewd nio4r uses libev for MRI. If the purpose of removing eventmachine was to have support for windows MRI, that won't do it, at least until someone port nio4r to libuv. |
|
|
||
| def self.secure_request?(env) | ||
| return true if env['HTTPS'] == 'on' | ||
| return true if env['HTTP_X_FORWARDED_SSL'] == 'on' |
There was a problem hiding this comment.
Might be wise to use Rack::Reqest#ssl? here.
There was a problem hiding this comment.
Or maybe it's better to use Rack::Reqest#scheme == 'https' then?
@TiagoCardoso1983 except on Windows, where it falls back to |
|
@matthewd what about socketry/nio4r#52? nio4r pure ruby implementation is quite untested and contains recursive locking issues. |
|
@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 notifications@github.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. |
No description provided.