Evaluate cases where resolver is likely to cause blocking behaviour

[ioquatix]

Under the hood, ruby often calls getaddrinfo to turn things like localhost into a struct sockaddr. This is often going to be a blocking operation, which will block the entire reactor.

I'd like to enumerate cases where blocking behaviour might be experienced (e.g. Async::TCPSocket.connect with a hostname), and figure out a solution.

[tarcieri]

The two that immediately come to mind are:

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

[ioquatix]

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

[ioquatix]

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.

[tarcieri]

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

[ioquatix]

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