1. 17

  2. 1

    My understanding is that this wasn’t done in the past, solely because every (most?) DNS interfaces were blocking. How are they handling that now?

    1. 6

      I am afraid you are mistaken, and the linked article gets some details wrong.

      On all suported platforms except Plan 9, the only way to do native name resolution is to link to libc (or equivalent system library). Normally this would make cross compilation hard, so Go came with its own name resolver.

      If Go were a standard toolchain, this is the best you could do, but the Go toolchain is non-standard. Very early in Go’s development the Go internal linker gained the ability to link to dynamic PE objects without having to have them available at build time. This was required by Windows port. Slightly later, I added the same feature for ELF, for the Solaris port. Windows and Solaris do not have stable system call ABIs, so the ability to link with the native libraries was crucial, and this special ability was also crucial for being able to cross-compile Go easily.

      The internal linker gained the same special capability for Mach-O much later than for PE and ELF. I can’t recall exactly when, but it’s been this way for a couple of years old by now. Once it got this capability, it would have been posible to use the system resolver on MacOS. I am not sure why this change only happened now.

      Notice that I didn’t say anything about blocking vs. non-blocking interfaces. It doesn’t matter, Go can use blocking interfaces just fine, in fact, most system calls are blocking. The Go runtime is a multithreaded system that implements m:n scheduling of goroutines onto threads.

      The article says that “[Go is] making the necessary syscalls directly”, but there are no system calls involved in name resolution, it’s all userspace libraries.