You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
@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.
weissi
changed the title
NIO's Resolver interface pretty much forces thread hops
NIO's Resolver interface pretty much forces thread hops for external Resolvers
May 27, 2023
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.
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 :).
swift-nio/Sources/NIOPosix/Resolver.swift
Line 32 in 5768317
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.
The text was updated successfully, but these errors were encountered: