f8bee2e94c
Related issue: #2250 Motivation: Prior to this commit, Netty's non blocking EventLoops were each assigned a fixed thread by which all of the EventLoop's I/O and handler logic would be performed. While this is a fine approach for most users of Netty, some advanced users require more flexibility in scheduling the EventLoops. Modifications: Remove all direct usages of threads in MultithreadEventExecutorGroup, SingleThreadEventExecutor et al., and introduce an Executor abstraction instead. The way to think about this change is, that each iteration of an eventloop is now a task that gets scheduled in a ForkJoinPool. While the ForkJoinPool is the default, one also has the ability to plug in his/her own Executor (aka thread pool) into a EventLoop(Group). Result: Netty hands off thread management to a ForkJoinPool by default. Users can also provide their own thread pool implementation and get some control over scheduling Netty's EventLoops |
||
|---|---|---|
| .. | ||
| collection | ||
| concurrent | ||
| internal | ||
| ConstantPoolTest.java | ||
| DefaultAttributeMapTest.java | ||
| HashedWheelTimerTest.java | ||
| NetUtilTest.java | ||
| RecyclerTest.java | ||
| ThreadDeathWatcherTest.java | ||