We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
Reproducible with:
require "socket" host = "fe80::1213:31ff:fe67:8b94" ip = IPAddr.new(host) udp = UDPSocket.new(ip.family) puts udp.sendmsg_nonblock("bla", 0, Socket.sockaddr_in(53, host), exception: false)
In CRuby, this raises No route to host - sendmsg(2) (Errno::EHOSTUNREACH), whereas in truffleruby, it return :wait_writable.
No route to host - sendmsg(2) (Errno::EHOSTUNREACH)
:wait_writable
Bottom line is, connectivity errors shouldn't be gobbled.
Observed this behaviour with 21.1.0
The text was updated successfully, but these errors were encountered:
@HoneyryderChuck Trying that script (+ require 'ipaddr') on CRuby I get:
require 'ipaddr'
$ ruby -v sendmsg.rb ruby 2.7.3p183 (2021-04-05 revision 6847ee089d) [x86_64-linux] 3
And the same on truffleruby-dev and 21.1.0.
Sorry, something went wrong.
Probably because your IPv6 connectivity works better (kudos to your ISP provider 😂 ).
Maybe try it out with some other unreachable IP?
You can set the following ip table rule:
ip route add unreachable 192.168.2.1
And use that IP. Also doable from within truffleruby's docker container.
Thanks, I could reproduce with that, fix coming.
68f5a76
[GR-18163] BasicSocket#*_nonblock(exception: false) should only retur…
8edb2ac
…n a Symbol for EAGAIN/EWOULDBLOCK (#2400) PullRequest: truffleruby/2800
BasicSocket#*_nonblock(exception: false) should only return a Symbol …
39fb174
…for EAGAIN/EWOULDBLOCK * Fixes oracle#2400
eregon
No branches or pull requests
Reproducible with:
In CRuby, this raises
No route to host - sendmsg(2) (Errno::EHOSTUNREACH)
, whereas in truffleruby, it return:wait_writable
.Bottom line is, connectivity errors shouldn't be gobbled.
Observed this behaviour with 21.1.0
The text was updated successfully, but these errors were encountered: