Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrade libev and fix Windows build #32

Merged
merged 2 commits into from
Jul 27, 2013
Merged

Upgrade libev and fix Windows build #32

merged 2 commits into from
Jul 27, 2013

Conversation

luislavena
Copy link
Contributor

Hello,

This pull request upgrades libev to version 4.15 and adjust the defines requires for Windows compilation.

Before this patch, it was not possible to build nio4r, with it, build succeed and spec pass, except for the following two:

  1) IO.pipe behaves like an NIO selectable does not select unwritable objects
     Failure/Error: monitor = selector.register(unwritable_subject, :w)
     Errno::EBADF:
       Bad file descriptor
     Shared Example Group: "an NIO selectable" called from ./spec/nio/selectables/pipe_spec.rb:36

  2) NIO::Selector timeouts waits for a timeout when selecting
     Failure/Error: reader.read_nonblock(payload.size)
     Errno::EBADF:
       Bad file descriptor
     # ./spec/nio/selector_spec.rb:78:in `read_nonblock'

These two failures seems related to a bug I reported to Ruby-Core a year ago:

https://bugs.ruby-lang.org/issues/5954

And this only happens with IO.pipe. Pipes should work transparently on Windows, but is clear that what IO.pipe is doing is not creating a compatible file descriptor for read_nonblock and requires further investigation.

This pull request should solve Issue #31

Cheers! ❤️ ❤️ ❤️

This version have some improvements for Windows.

Made manual update and verified patches (hacks) still apply.
These are present in POSIX OS, not Windows, so we avoid enabling
such functionality.
@coveralls
Copy link

Coverage Status

Coverage increased (+0%) when pulling 0df22fd on luislavena:upgrade-libev into ad291fc on celluloid:master.

tarcieri added a commit that referenced this pull request Jul 27, 2013
Upgrade libev and fix Windows build
@tarcieri tarcieri merged commit 19623b2 into socketry:master Jul 27, 2013
@tarcieri
Copy link
Contributor

Thank you so much! You rock! 😺

@SaitoWu
Copy link

SaitoWu commented Jul 27, 2013

Nice! :shipit: :shipit: :shipit:

@ivey
Copy link

ivey commented Aug 1, 2013

Could we get a new version released?

@tarcieri
Copy link
Contributor

tarcieri commented Aug 1, 2013

Soon! ;)

Tony Arcieri

On Aug 1, 2013, at 1:31 PM, "Michael D. Ivey" notifications@github.com
wrote:

Could we get a new version released?


Reply to this email directly or view it on
GitHubhttps://github.com//pull/32#issuecomment-21967466
.

@tarcieri
Copy link
Contributor

tarcieri commented Aug 7, 2013

nio4r 0.5.0 has been released! /cc @ivey

@SaitoWu
Copy link

SaitoWu commented Aug 7, 2013

Whoa!!

@SaitoWu
Copy link

SaitoWu commented Aug 8, 2013

@luislavena Hi, I'm using Reel for a WebSocket server.

And i found an issue same as guard/guard-livereload#69 :

LoadError: cannot load such file -- 2.0/ruby_http_parser

Seems like it just happens in Windows and Ruby 2.0, Is there any solutions to pass it?

@tarcieri
Copy link
Contributor

tarcieri commented Aug 8, 2013

@SaitoWu lame! That is most likely an issue with https://github.com/tmm1/http_parser.rb

@luislavena
Copy link
Contributor Author

@SaitoWu the http_parser.rb gem needs to be cross-compiled to include Ruby 2.0 binaries.

This can be avoided by simply uninstalling that gem and installing it again with gem install http_parser.rb --platform=ruby

@stakach
Copy link
Contributor

stakach commented Sep 12, 2013

One could use an alternative ffi version of http_parser: https://github.com/cotag/http-parser
Of course the API will probably be a little different however happy for people to contribute - works on all platforms and rubies

@tarcieri
Copy link
Contributor

@stakach the nice thing about the current library is it has a pure-Java JRuby version that exposes the same API

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants