NIO's Resolver interface pretty much forces thread hops for external Resolvers

[weissi]

https://github.com/apple/swift-nio/blob/5768317b704288e172b2dc927e7927f4c16843be/Sources/NIOPosix/Resolver.swift#L32

NIO's resolver interface doesn't tell the resolver what EventLoop the returned future should ideally be coming from. That means that a normal resolver will likely return futures of a random EL which is bad for performance and unnecessary.

NIO's own GAIResolver kinda cheats and gets constructed inside ClientBootstrap -- after it has selected the EL for the new Channel. That possibility doesn't exist for outside resolvers because they need to be initialised when added to ClientBootstrap.resolver(instanceHere).

yes, you can manually pick an EL, pass that to the ClientBootstrap as the group and also pass it to your resolver but that's brittle, error-prone, reimplementing NIO functionality and probably also precludes a multi-shot resolver from caching.

[weissi]

@Lukasa should we invent a new label like needs-major that is something like easy-in-major-challenging-in-minor for issues (like this one) that are possible (but ugly/hard) to be fixed in minors (adding new interfaces that overlap with old ones) but would be incredibly easy in a minor.

Then once NIO3 comes around they can just be done.

[dnadoba]

If you know the EventLoopGroup you can use .any() to get the "current" EventLoop and avoid thread hops without passing the EventLoop to any of the Resolver methods explicitly because they are called while being on the EventLoop.

[weissi]

If you know the EventLoopGroup you can use .any() to get the "current" EventLoop and avoid thread hops without passing the EventLoop to any of the Resolver methods explicitly because they are called while being on the EventLoop.

Sure, but that's not "guaranteed" to work and just unnecessarily ugly :).