ForkJoinPool-based EventLoopGroup and Channel Deregistration

Hey,

this is a first version of Netty running on a ForkJoinPool and deregister (hopefully) working correctly. The main idea behind the changes in deregister is that deregister is always executed as a task and never invoked directly. We also do not allow any new task submissions after deregister was called, making the deregistration task the last task of a particular Channel in the task queue and we thus do not have to worry about moving tasks between EventLoops. We achieve this mainly by wrapping all calls to .eventLoop() and .executor(). There is some special treatment required for scheduled tasks, but this is best explained in the code.

Let me know what you guys think.

@normanmaurer @trustin
+1

> Am 11.08.2014 um 20:54 schrieb Trustin Lee <notifications@github.com>:
> 
> In transport/src/main/java/io/netty/channel/DefaultChannelHandlerContext.java:
> 
> > @@ -35,4 +39,78 @@ private static ChannelHandler checkNull(ChannelHandler handler) {
> >      public ChannelHandler handler() {
> >          return handler;
> >      }
> > +
> > +    @Override
> > +    public EventExecutor executor() {
> > +        // If the ChannelHandler does not have its own
> > +        // invoker/eventloop we can reuse the wrapped
> > +        // eventloop of the channel.
> > +        if (invoker == null) {
> > +            return channel().eventLoop();
> > +        } else {
> > +            // Double checked locking.
> > +            if (wrapped == null) {
> > +                synchronized (this) {
> > +                    if (wrapped == null) {
> > +                        wrapped = new PausableChannelEventExecutorImpl();
> Not that I like the solution I suggested. :-)
> 
> Of course, a fully asynchronous application will be OK, but we need to consider this use case: a user wants to specify an executor or a custom invoker in the pipeline and the pipeline is pretty long, and channels are short-living. e.g. 10 handlers total. 8 of 10 need to be run on a custom invoker = 8 extra objects per channel.
> 
> Anyways, I'm fine with leaving this as is for now. We should probably take care of this later.
> 
> —
> Reply to this email directly or view it on GitHub.