[xpressvideoz]

> Name resolution such as `Socket.getaddrinfo` can now be interrupted. Whenever it needs name resolution, it creates a worker pthread, and executes `getaddrinfo(3)` in it.

Do other language runtimes do similar things? Creating a thread sounds too heavy, though it might not matter in practice. As per their own benchmark, the overhead is minimal but still not zero.

  10000.times { 
  Addrinfo.getaddrinfo("www.ruby- 
  lang.org", 80) }
  # Before patch: 2.3 sec.
  # After ptach: 3.0 sec.

  100.times { 
  URI.open("https://www.ruby-lang.org").read }
  # Before patch: 3.36 sec.
  # After ptach: 3.40 sec.

[nerdponx]

Is this because all of the I/O operations in the standard library have to support async/fibers?

My impression is that everything was migrated to be asynchronous by default, unlike in Python where all of these operations were reimplemented in the async "color". Is that true?

[Alifatisk]

Wouldn’t a fiber be more lightweight than having to create a new thread?

[byroot]

A fiber doesn't have a dedicated execution context, so it would be just as blocking.

[Alifatisk]

Is there really no other way than creating a whole thread for this?

[viraptor]

You can use a pure ruby resolver if you want. For example https://github.com/socketry/async-dns

But that way your sacrificing integration into your system's nsswitch which may want to do something completely different with your requests.

You could also query over dbus which can be async https://www.freedesktop.org/software/systemd/man/latest/org.... (if you can depend on systemd)

[byroot]

There is a few alternatives like getaddrinfo_a(3) but they have other downsides (fork safety concerns).

If you want more context, you can read: https://bugs.ruby-lang.org/issues/19430

[chucke]

The getaddrinfo interface does not expose the fd so you can monitor for readiness. Several languages have the same problem with it, some with similar solutions (go outsources getaddrinfo calls to a thread pool)