4 ms·
> Name resolution such as `Socket.getaddrinfo` can now be interrupted. Whenever it needs name resolution, it creates a worker pthread, and executes `getaddrinfo
by xpressvideoz 3y ago
> 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.
- Alifatisk 3y agoWouldn’t a fiber be more lightweight than having to create a new thread?
- byroot 3y agoA fiber doesn't have a dedicated execution context, so it would be just as blocking.
- Alifatisk 3y agoIs there really no other way than creating a whole thread for this?
- viraptor 3y agoYou can use a pure ruby resolver if you want. For example https://github.com/socketry/async-dns 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.freedesktop.resolve1.html https://www.freedesktop.org/software/systemd/man/latest/org.... (if you can depend on systemd)
- byroot 3y agoThere 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 https://bugs.ruby-lang.org/issues/19430
- chucke 3y agoThe 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)
- nerdponx 3y agoIs 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?