Project

General

Profile

Feature #14430

net/http: use Socket.tcp with connect_timeout, instead of TCPSocket.open wrapped in Timeout.timeout

Added by carl.hoerberg (Carl H├Ârberg) 4 months ago. Updated 4 months ago.

Status:
Open
Priority:
Normal
Assignee:
-
Target version:
-
[ruby-core:85324]

Description

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.

PR at: https://github.com/ruby/ruby/pull/1806

History

#1 [ruby-core:85327] Updated by normalperson (Eric Wong) 4 months ago

carl.hoerberg@gmail.com wrote:

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:

1) implement Timeout in the VM itself so it doesn't need to create
a temporary thread.

2) update resolv-replace.rb to cover Addrinfo cases, including
nscd cache lookup for glibc compatibility.

#2 [ruby-core:85331] Updated by shevegen (Robert A. Heiler) 4 months ago

implement Timeout in the VM itself so it doesn't need
to create a temporary thread.

There be dragons hiding in the VM.

\o/

#3 [ruby-core:85374] Updated by carl.hoerberg (Carl H├Ârberg) 4 months ago

normalperson (Eric Wong) wrote:

Unfortunately, we can't do this, yet. The Addrinfo calls use
getaddrinfo(3) which doesn't support timeout natively.

Right, good catch.

2) 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?

Also available in: Atom PDF