Evaluate cases where resolver is likely to cause blocking behaviour about async HOT 5 CLOSED

The two that immediately come to mind are:

• Failing to receive a response from a local cache
• Timing out talking to upstream servers

from async.

What we should probably do is provide explicit guarantees about blocking and non-blocking behaviour, and document it.

Additionally, I've filed some bugs with Ruby, which affect this:

https://bugs.ruby-lang.org/issues/13407
https://bugs.ruby-lang.org/issues/13409

from async.

I've thought about this more. I've implemented a generic API on top of Socket, which uses Addrinfo. I assume this method blocks when converting to sockaddr as it may need to consult DNS/name resolution. This gives a simple point where we may block when converting names into addresses.

from async.

I can't remember exactly why, but I used IPSocket.getaddress here:

https://github.com/socketry/socketry/blob/master/lib/socketry/resolver/system.rb#L26

from async.

The core async gem has been simplified to the point where these issues are not a concern. However, they will now be a concern of async-io and other things that build on async. There is little we can do, for example, to avoid blocking the reactor if a user calls Dir.glob - except perhaps simplify the usage of thread-pools do make it easier for a user to do, say task.blocking { Dir.glob }.

from async.