3 ms·

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

• byroot 3y ago
  A fiber doesn't have a dedicated execution context, so it would be just as blocking.
  • Alifatisk 3y ago
    Is there really no other way than creating a whole thread for this?
    • viraptor 3y ago
      You 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 ago
      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 https://bugs.ruby-lang.org/issues/19430
• chucke 3y ago
  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)