Netty(3): EventLoop

We have discussed the Handler design in last blog: the InboundHandler & OutboundHandler, the handler & childHandler, the Servlet vs Handler. In this blog, we will dive into the thread pool abstraction in Netty – EventLoop.

EventLoop Basic

From our previous code example, we can see that what we used are EventLoopGroup, which is a group of EventLoops, but what is EventLoop on earth?

Loop & Pool

The EventLoop, as its name indicates, is a infinite loop to handle IO events. A common implementation (NioEventLoop) is like following:

protected void run() {  
  for (;;) {  
    try {  
      switch (selectStrategy.calculateStrategy(selectNowSupplier, hasTasks())) {  
        case SelectStrategy.CONTINUE:  
          continue;  
        case SelectStrategy.SELECT:  
          select(wakenUp.getAndSet(false));  
  
          if (wakenUp.get()) {  
            selector.wakeup();  
          }  
        default:  
          // fallthrough  
       }  
  
      if (ioRatio == 100) {  
        try {  
          processSelectedKeys();  
        } finally {  
          // Ensure we always run tasks.  
          runAllTasks();  
        }  
      
        // ...
      }  
    } catch (Throwable t) {  
      handleLoopException(t);  
    }  
  }  
}

When processSelectedKeys, EventLoop may use different worker thread to run the tasks that IO event brings. So, EventLoop is also a thread pool.

In conclusion, EventLoop is

EventLoop = Event Dispatcher + Thread Pool (worker to handle IO events from `Channel`s)

Channel Registration

In order to have the functionality to do the Event Dispatch, Channel have to be registered in it, just like what we did in Java NIO:

servChannel.register(selector, SelectionKey.OP_ACCEPT);

And EventLoopGroup's comment proves it:

/**
  * Special  [`EventExecutorGroup`]  which allows registering  [`Channel`]s that get    
  * processed for later selection during the event loop.
  */
public interface EventLoopGroup extends EventExecutorGroup {
  ChannelFuture register(Channel channel);
}

Different Impliementations

Netty has many different ementations for EventLoop:

DefaultEventLoop, NioEventLoop, SingleThreadEventLoop, ThreadPerChannelEventLoop etc

SingleThreadEventLoop is the base class for DefaultEventLoop, NioEventLoop, ThreadPerChannelEventLoop, which run all task in a single thread.

ThreadPerChannelEventLoop is a implementation for OIO, where every Channel needs a thread. Today, we focus on NIO related (IO multiplex) implementations, which is more widely used.

NioEventLoop

NioEventLoop, which uses Java NIO as its underlying implementation, is actually a single thread pool. The coe concept in Java NIO is Channel, Selector, Buffer. We can find the usage of Channel and Buffer (although they are wrapped by Netty's class and we will clarify them later in this serial of blog).
And the functionality of Selector, which is the IO event dispatcher and choosing the right IO related code to execute is encapsulated in NioEventLoop as following code shows (notice that the real IO event handling is what Handler does, i.e. EventLoop will just call Handler).

private void processSelectedKey(SelectionKey k, AbstractNioChannel ch) {  
  try {  
    int readyOps = k.readyOps();  
    if ((readyOps & SelectionKey.OP_CONNECT) != 0) {  
      int ops = k.interestOps();  
      ops &= ~SelectionKey.OP_CONNECT;  
      k.interestOps(ops);  
  
      unsafe.finishConnect();  
    }  
  
    // Process OP_WRITE first as we may be able to write some queued buffers and so free memory.  
  if ((readyOps & SelectionKey.OP_WRITE) != 0) {  
      // Call forceFlush which will also take care of clear the OP_WRITE once there is nothing left to write  
      ch.unsafe().forceFlush();  
    }  
  
    // Also check for readOps of 0 to workaround possible JDK bug which may otherwise lead  
    // to a spin loop  
     if ((readyOps & (SelectionKey.OP_READ | SelectionKey.OP_ACCEPT)) != 0 || readyOps == 0) {  
      unsafe.read();  
    }  
  } catch (CancelledKeyException ignored) {  
    unsafe.close(unsafe.voidPromise());  
  }  
}

EpollEventLoop

If we work in Linux and want higher throughput, we can use EpollEventLoop. It is implemented by JNI, which will invoke the system call like epoll (it is only works on linux).

Compared with NioEventLoop, EpollEventLoop has following advantages:

• It is edge-triggered, rather than level-triggered like NioEventLoop, which is more efficient as here said;
• It is implemented by C, which means
  • It will cause less GC activity;
  • It needs less synchronized;
  • It can expose more Socket config option than using Java's Socket;

Thread Issue

When it comes to the Thread Pool and multiple thread coding, we need to be careful about the race conditions it may causes. So we need to find which thread will run the callback:

for a given connection, there can not be more than one wire runtime running ChannelsHandler code and functions back associates. In other words, within a ChannelPipeline, there is no need to worry about access competition issues, so we stay in this logic of not blocking the wires execution.

As the document specified, we don’t need to worry about the race condition if we don’t share variables using global variables. But this also require that our handler code not too time-consuming, otherwise the worker will be stuck and EventLoop can’t dispatch events.

This non-access competition relies on an event loop that reuses a small number of threads executions that never get stuck, which makes it possible to maximize performance by reducing switching times betweethreads of execution.

Ref

• A Chinese blog post
• EventLoopGroup
• EventLoop
• Simple Netty example

Written with StackEdit.