[Netty5] ChannelPipeline mutating methods signature

All the methods that mutate the ChannelPipeline are currently “synchronous”. This means all manipulation of the pipeline must complete before modifier methods return, and theChannelPipeline implementation must therefore account for concurrency. All of the interaction with the ChannelPipeline is inside the EventLoop and we can therefore delay modification until we are in the EventLoop. This will reduce complexity of the ChannelPipeline implementation, and also remove the current “best effort” concurrency code in AbstractChannelHandlerContext.

There are currently 2 different ideas here:

1. Have all methods just return ChannelFuture which completes when the pipeline is modified (e.g. on the EventLoop). If we do this we also most likely should allow to pass in a ChannelPromise that is used for notifications.
2. Only allow pipeline modifications on the EventLoop.

I am currently in favour of 1) as this is also what we did in SwiftNIO with great success and still will allow people to just use ChannelPipeline from “any thread”.

[normanmaurer]

@nicktrav I like your idea. That said we may still want to return a Future (not sure about this yet).

@RoganDawes I think we should just not support the “varargs” anymore to fix the problem. About how this would look like when we return futures, I think we would allow to chain calls via some lambdas.

[njhill]

@normanmaurer is this obsolete in light of #8778?

Related to this and #8156, I had another idea w.r.t. the pipeline manipulation API design, i.e. how best to reference handlers after they are added. Why not have all the addX/replace methods return the new handler context, and move all of the addBefore, addAfter, replace, remove methods from the pipeline to the context?

I think this would address most/all of the frustrations raised in #8156, including most of the cartesian product explosion. You could do things such as:

channel.pipeline().addFirst(handler1).addAfter(handler2, "myname").addAfter(handler3);

channel.pipeline().context("myname").replace(handler4);

MyHandler removed = channel.pipeline().context(MyHandler.class).remove();

etc.

If we still want to avoid the synchronization here, all these methods could instead return Future<ChannelHandlerContext> along the lines of your suggestion 1 above.

cc @ejona86