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
The badly named but highly useful .delegate(on:) specifies two things:
Which EventLoop the returned futures are bound to
Which EventLoop the delegate callouts happen on.
Crucially it does not specify on what EventLoop the underlying Channels are running on. Yes, as an optimisation if possible & sensible (i.e. the connection pool doesn't already have a valid connection) we try to create new Channels on the same EventLoop but that's neither guaranteed nor required.
Expected behaviour
If I pass a random EventLoop to AHC's eventLoop: .delegate(on: myRandomEL) then I would expect this to work, even if AHC itself is using an EventLoopGroup that doesn't contain my EventLoop for its Channels.
Actual behaviour
AHC crashes and tells me that I can only use EventLoops from AHC's EventLoopGroup at runtime. That's bad an unnecessary.
The text was updated successfully, but these errors were encountered:
The badly named but highly useful
.delegate(on:)
specifies two things:EventLoop
the returned futures are bound toEventLoop
the delegate callouts happen on.Crucially it does not specify on what
EventLoop
the underlyingChannel
s are running on. Yes, as an optimisation if possible & sensible (i.e. the connection pool doesn't already have a valid connection) we try to create newChannel
s on the sameEventLoop
but that's neither guaranteed nor required.Expected behaviour
If I pass a random
EventLoop
to AHC'seventLoop: .delegate(on: myRandomEL)
then I would expect this to work, even if AHC itself is using anEventLoopGroup
that doesn't contain myEventLoop
for itsChannel
s.Actual behaviour
AHC crashes and tells me that I can only use
EventLoop
s from AHC'sEventLoopGroup
at runtime. That's bad an unnecessary.The text was updated successfully, but these errors were encountered: