netty5/transport/src/main/java/io/netty/channel/EventLoop.java

31 lines
1.0 KiB
Java
Raw Normal View History

2012-06-04 22:31:44 +02:00
/*
* Copyright 2012 The Netty Project
*
* The Netty Project licenses this file to you under the Apache License,
* version 2.0 (the "License"); you may not use this file except in compliance
* with the License. You may obtain a copy of the License at:
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
* WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
* License for the specific language governing permissions and limitations
* under the License.
*/
package io.netty.channel;
[#5486] Not operate on serial execution assumption when using EventExecutor in the DefaultChannelPipeline. Motivation: In commit f984870ccca133d6056e8b0df0b2352f8f90b0fe I made a change which operated under invalide assumption that tasks executed by an EventExecutor will always be processed in a serial fashion. This is true for SingleThreadEventExecutor sub-classes but not part of the EventExecutor interface contract. Because of this change implementations of EventExecutor which not strictly execute tasks in a serial fashion may miss events before handlerAdded(...) is called. This is strictly speaking not correct as there is not guarantee in this case that handlerAdded(...) will be called as first task (as there is no ordering guarentee). Cassandra itself ships such an EventExecutor implementation which has no strict ordering to spread load across multiple threads. Modifications: - Add new OrderedEventExecutor interface and let SingleThreadEventExecutor / EventLoop implement / extend it. - Only expose "restriction" of skipping events until handlerAdded(...) is called for OrderedEventExecutor implementations - Add ThreadPoolEventExecutor implementation which executes tasks in an unordered fashion. This is used in added unit test but can also be used for protocols which not expose an strict ordering. - Add unit test. Result: Resurrect the possibility to implement an EventExecutor which does not enforce serial execution of events and be able to use it with the DefaultChannelPipeline.
2016-07-03 22:28:47 +02:00
import io.netty.util.concurrent.OrderedEventExecutor;
/**
2015-02-03 20:54:48 +01:00
* Will handle all the I/O operations for a {@link Channel} once registered.
*
2015-11-19 09:02:45 +01:00
* One {@link EventLoop} instance will usually handle more than one {@link Channel} but this may depend on
* implementation details and internals.
*
*/
[#5486] Not operate on serial execution assumption when using EventExecutor in the DefaultChannelPipeline. Motivation: In commit f984870ccca133d6056e8b0df0b2352f8f90b0fe I made a change which operated under invalide assumption that tasks executed by an EventExecutor will always be processed in a serial fashion. This is true for SingleThreadEventExecutor sub-classes but not part of the EventExecutor interface contract. Because of this change implementations of EventExecutor which not strictly execute tasks in a serial fashion may miss events before handlerAdded(...) is called. This is strictly speaking not correct as there is not guarantee in this case that handlerAdded(...) will be called as first task (as there is no ordering guarentee). Cassandra itself ships such an EventExecutor implementation which has no strict ordering to spread load across multiple threads. Modifications: - Add new OrderedEventExecutor interface and let SingleThreadEventExecutor / EventLoop implement / extend it. - Only expose "restriction" of skipping events until handlerAdded(...) is called for OrderedEventExecutor implementations - Add ThreadPoolEventExecutor implementation which executes tasks in an unordered fashion. This is used in added unit test but can also be used for protocols which not expose an strict ordering. - Add unit test. Result: Resurrect the possibility to implement an EventExecutor which does not enforce serial execution of events and be able to use it with the DefaultChannelPipeline.
2016-07-03 22:28:47 +02:00
public interface EventLoop extends OrderedEventExecutor, EventLoopGroup {
@Override
EventLoopGroup parent();
}