5 ms·

Netscape used to start a new thread (or maybe it was a subprocess?) to handle DNS lookups, because the API at the time (gethostbyname) was blocking. It's kind

• fpoling 1y ago
  In 1996 it was a subprocess. Linux Threads appeared only later that year.
• nly 1y ago
  If you want DNS resolution to obey user/system preferences then you need to use the system provided API
  • rwmj 1y ago
    For sure! The only problem is there should be a non-blocking system-provided API and there isn't.
    • foota 1y ago
      System provided is maybe a strange word to use here since getaddrinfo is a libc function, not a system call.
      • rwmj 1y ago
        POSIX as the system, of course.
      • froh 1y ago
        the system API is not syscalls but libc. so why does it feel strange?
  • Seattle3503 1y ago
    In this case it isn't in the kernel, but in glibc. Could someone implement an equivalent alternative? Do any language runtimes re-implement DNS resolution?
    • NewJazz 1y ago
      I think most languages use the OS api by default, but there are plenty of libraries out there that bypass the system resolution.
    • bradfitz 1y ago
      Go does. And it supports timeouts and cancelation.
  • tremon 1y ago
    The system-provided API for getting DNS user/system preferences on Unix systems is to read /etc/resolv.conf. Every application is free to implement their own lookup from that.
    • dcrazy 1y ago
      That is absolutely not the API on macOS, which is a certified UNIX.
    • Spivak 1y ago
      This isn't even correct on Linux as it won't work if your user has anything other than or in addition to the dns module in their nsswitch.conf. You must use glibc's resolution on Linux for correct behavior. If it's software on your own systems then do what you want but you'll piss off some sysadmins deploying your software if you don't. Even Go farms out to cgo to resolve names if it detects modules it doesn't recognize.
• silon42 1y ago
  As long as broken APIs exist, they will be problematic... they really should be deprecated. Calling a separate (non-cancellable) thread to perform the lookup sounds a like viable solution...
• jeroenhd 1y ago
  getaddrinfo_a is available, but not widely adopted (*BSD and Linux), probably because you can't guarantee it'll be available on every computer/phone/modem. This is only an issue if you're targeting POSIX rather than modern operating systems. Windows 8 and above also have their own asynchronous DNS API on NON-POSIX land.
  • rfl890 1y ago
    >Windows 8 and above also have their own asynchronous DNS API on NON-POSIX land. Interesting. Which API?
    • poizan42 1y ago
      GetAddrInfoEx[0] has async support support since Windows 8 - it had the overlapped parameters earlier but didn't support them. I'm guessing that is what GP is referring to. [0] https://learn.microsoft.com/en-us/windows/win32/api/ws2tcpip/nf-ws2tcpip-getaddrinfoexw https://learn.microsoft.com/en-us/windows/win32/api/ws2tcpip...
  • Arnavion 1y ago
    >getaddrinfo_a is available, but not widely adopted (*BSD and Linux), probably because you can't guarantee it'll be available on every computer/phone/modem. This is only an issue if you're targeting POSIX rather than modern operating systems. To be precise, even on Linux getaddrinfo_a is not guaranteed to be present. It's a glibc extension. musl doesn't have it.
    • o11c 1y ago
      And MUSL's explicit policy of "do not implement essential features, just because the standards are falling behind" is a major reason why many programs choose to never support building against MUSL.
      • pjz 1y ago
        Funny, I see it as them choosing not to add another de-facto 'standard' ala https://xkcd.com/927/ https://xkcd.com/927/ .