Instead of using TCPSocket.open, wrapped in Timeout.timeout, that will create a temporary thread. By using Socket.tcp with the connect_timeout argument for open_timeout the connection opening is much more efficient as the kernels timeout is used instead.
Instead of using TCPSocket.open, wrapped in Timeout.timeout,
that will create a temporary thread. By using Socket.tcp with
the connect_timeout argument for open_timeout the connection
opening is much more efficient as the kernels timeout is used
instead.
Unfortunately, we can't do this, yet. The Addrinfo calls use
getaddrinfo(3) which doesn't support timeout natively.
My goals for later this year is:
implement Timeout in the VM itself so it doesn't need to create
a temporary thread.
update resolv-replace.rb to cover Addrinfo cases, including
nscd cache lookup for glibc compatibility.
Unfortunately, we can't do this, yet. The Addrinfo calls use
getaddrinfo(3) which doesn't support timeout natively.
Right, good catch.
update resolv-replace.rb to cover Addrinfo cases, including
nscd cache lookup for glibc compatibility.
Looking into this i realize that /etc/nsswitch.conf has be to taken into account first. And then maybe nscd, but very few distros (if any?) install it by default anymore, and it generally seems to have a very bad rep "around the internets".
But which one do you suggest? Go down the route of Socket.tcp, but make the DNS resolving interruptible/async (without doing it in a separate threads) or to implement thread-less timeout in the VM and continue to rely on getinfoaddr from glibc?
The PR is updated, based on master and adds Net::HTTP#resolve_timeout, which delegates to Socket.tcp resolve_timeout, based on https://bugs.ruby-lang.org/issues/16381 but reraiseing Errno::ETIMEOUT as Net::OpenTimeout
Updated by 
Updated by 
Updated by 
Updated by 
Updated by