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 of amazing that we're 30 years on and this is still a problem.

▲

jeroenhd 3 days ago | parent | next [-]

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.

▲

Arnavion 3 days ago | parent | next [-]

>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 3 days ago | parent [-]

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 2 days ago \| parent [-]
		Funny, I see it as them choosing not to add another de-facto 'standard' ala https://xkcd.com/927/ .

▲

rfl890 3 days ago | parent | prev [-]

>Windows 8 and above also have their own asynchronous DNS API on NON-POSIX land. Interesting. Which API?

	▲	poizan42 3 days ago \| parent [-]
		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...

▲

nly 3 days ago | parent | prev | next [-]

If you want DNS resolution to obey user/system preferences then you need to use the system provided API

▲

rwmj 3 days ago | parent | next [-]

For sure! The only problem is there should be a non-blocking system-provided API and there isn't.

▲

foota 3 days ago | parent [-]

System provided is maybe a strange word to use here since getaddrinfo is a libc function, not a system call.

	▲	rwmj 3 days ago \| parent \| next [-]
		POSIX as the system, of course.
	▲	froh 3 days ago \| parent \| prev [-]
		the system API is not syscalls but libc. so why does it feel strange?

▲

tremon 3 days ago | parent | prev | next [-]

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.

	▲	Spivak 3 days ago \| parent \| next [-]
		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.
	▲	dcrazy 3 days ago \| parent \| prev [-]
		That is absolutely not the API on macOS, which is a certified UNIX.

▲

Seattle3503 3 days ago | parent | prev [-]

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 3 days ago \| parent \| next [-]
		I think most languages use the OS api by default, but there are plenty of libraries out there that bypass the system resolution.
	▲	bradfitz 3 days ago \| parent \| prev [-]
		Go does. And it supports timeouts and cancelation.

▲

fpoling 2 days ago | parent | prev | next [-]

In 1996 it was a subprocess. Linux Threads appeared only later that year.

▲

silon42 3 days ago | parent | prev [-]

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...