a64484249c
Motiviation: Before this change, autoRead was a volatile boolean accessed directly. Any thread that invoked the DefaultChannelConfig#setAutoRead(boolean) method would read the current value of autoRead, and then set a new value. If the old value did not match the new value, some action would be immediately taken as part of the same method call. As volatile only provides happens-before consistency, there was no guarantee that the calling thread was actually the thread mutating the state of the autoRead variable (such that it should be the one to invoke the follow-up actions). For example, with 3 threads: * Thread 1: get = false * Thread 1: set = true * Thread 1: invokes read() * Thread 2: get = true * Thread 3: get = true * Thread 2: set = false * Thread 2: invokes autoReadCleared() * Event Loop receives notification from the Selector that data is available, but as autoRead has been cleared, cancels the operation and removes read interest * Thread 3: set = true This results in a livelock - autoRead is set true, but no reads will happen even if data is available (as readyOps). The only way around this livelock currently is to set autoRead to false, and then back to true. Modifications: Write access to the autoRead variable is now made using the getAndSet() method of an AtomicIntegerFieldUpdater, AUTOREAD_UPDATER. This also changed the type of the underlying autoRead variable to be an integer, as no AtomicBooleanFieldUpdater class exists. Boolean logic is retained by assuming that 1 is true and 0 is false. Result: There is no longer a race condition between retrieving the old value of the autoRead variable and setting a new value. |
||
|---|---|---|
| all | ||
| buffer | ||
| codec | ||
| codec-dns | ||
| codec-haproxy | ||
| codec-http | ||
| codec-memcache | ||
| codec-mqtt | ||
| codec-socks | ||
| codec-stomp | ||
| common | ||
| example | ||
| handler | ||
| license | ||
| microbench | ||
| tarball | ||
| testsuite | ||
| transport | ||
| transport-native-epoll | ||
| transport-rxtx | ||
| transport-sctp | ||
| transport-udt | ||
| .fbprefs | ||
| .gitignore | ||
| .travis.yml | ||
| CONTRIBUTING.md | ||
| LICENSE.txt | ||
| NOTICE.txt | ||
| pom.xml | ||
| README.md | ||
| run-example.sh | ||
Netty Project
Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients.
Links
How to build
For the detailed information about building and developing Netty, please visit the developer guide. This page only gives very basic information.
You require the following to build Netty:
- Latest stable Oracle JDK 7
- Latest stable Apache Maven
- If you are on Linux, you need additional development packages installed on your system, because you'll build the native transport.
Note that this is build-time requirement. JDK 5 (for 3.x) or 6 (for 4.0+) is enough to run your Netty-based application.
Branches to look
The 'master' branch is where the development of the latest major version lives on. The development of all other versions takes place in each branch whose name is identical to <majorVersion>.<minorVersion>. For example, the development of 3.9 and 4.0 resides in the branch '3.9' and the branch '4.0' respectively.