Tags: keke233/swift-nio
Tags
fix AtomicBox by deprecating it and implementing it with a CAS loop (a… …pple#1287) Motivation: Atomic references cannot easily be maintained correctly because the `load` operation gets a pointer value that might (before the loader gets a change to retain the returned reference) be destroyed by another thread. Modifications: - Deprecate `AtomicBox` - Implement `NIOCASLoopBox` with functionality similar to AtomicBox (but implemented using a CAS loop :( ). Result: - fixes apple#1286
Fix running run-nio-alloc-counter-tests.sh for a single test (apple#1245 ) Motivation: Using the single test argument with the run-nio-alloc-counter-tests.sh does not work as expected as the given test would just replace the first test in the list. Modifications: Replace the tests to run with a single-element array containing the test provided as an argument. Result: - A single test can be run when specified as a command line arg.
Allow single test to be specified as an argument to run-nio-alloc-cou… …nter-tests.sh. (apple#1214) * Allow single test to be specified as an argument to run-nio-alloc-counter-tests.sh. Motivation: run-nio-alloc-counter-tests.sh currently runs all tests. When writing or debugging a test, you commonly want to run a single test. At the moment the common practice is to edit the script to hardcode a test to run, which is annoying and error-prone. Modifications: Add an optional argument to the script to specify the test to run. Result: $ ./run-nio-alloc-counter-tests.sh runs all tests. $ ./run-nio-alloc-counter-tests.sh test_decode_1000_ws_frames.swift runs only test_decode_1000_ws_frames.swift.
Add option to reserve writable capacity to writeWithUnsafeMutableBytes ( apple#1105) (apple#1175) Motivation: writeWithUnsafeMutableBytes cannot tolerate arbitrarily large writes because it is not possible to resize the buffer by the time body receives the buffer pointer. This change provides an option for the user to reserve writable capacity before the pointer is passed to body. Modifications: Added a backward compatible optional parameter to writeWithUnsafeMutableBytes which can reserve writable capacity before the pointer is passed to body. Result: Additive change only. Users can optionally specify a minimum writable capacity when calling writeWithUnsafeMutableBytes.
Allow promises to be completed with a `Result<Value, Error>` (apple#1124 ) Motivation: When dealing with `Result` types and promises it is inconvenient having to switch over the result in order to succeed or fail a promise. Modifications: - Allow promises to be completed with a `Result<Value, Error>` directly. - Added tests. Result: Promises are easier to fulfill with `Result` types.
BaseSocketChannel: accept immediately closed socket (apple#1121) Motivation: In the grpc-swift test suite, we saw a case where the server would always immediately close the accepted socket. This lead NIO to misbehave badly because kqueue would send us the `readEOF` before the `writable` event that finishes an asynchronous `connect`. What happened is that we just dropped the `readEOF` on the floor so we would never actually tell the user if the channel ever went away. Modifications: Only register for `readEOF` after becoming active. Result: - we're happy with servers that immediately close the socket
Remove `cpp_magic.h` import and ancient Clang compatibility hack from… … `CNIOAtomics.h` (apple#1111) The inclusion of `cpp_magic.h` in `CNIOAtomics.h` is unnecessary and pollutes the namespace of anyone else importing the header. NIO now also requires Swift 5, which itself will not be built with a Clang too old to understand `_Nonnull`. Note: Removing the extra import of cpp-magic.h required moving it to the src/ directory to avoid complaints about its inclusion (or lack thereof) in the module's umbrella header.
Fail promise in MessageToByteHandler write error cases (apple#1096) * Fail promise in MessageToByteHandler write error cases * Add test case for MessageToByteHandler failing write promises
fix double remove of handlers (apple#1091) * fix double remove of handlers Motivation: Previously, it was possible that a handler was removed twice: Once by Channel teardown and another time by a user-trigger removal that wasn't instantaneous. This racy situation can happen in the real world. NIO behaved wrongly in two ways: 1. we would call `handlerRemoved` twiced 2. ByteToMessageHandler would fail an assertion about the current removal state Modifications: - Only call `handlerRemoved` when the handler actually gets removed. - Fix the assertion. Result: fewer bugs * Update Sources/NIO/ChannelPipeline.swift Co-Authored-By: Cory Benfield <lukasa@apple.com>
Make pipeline handler behave better when removed (apple#1080) Motivation: The HTTPServerPipelineHandler is removed from pipelines in many cases, but the most common case is over upgrade. While the handler is removable, it doesn't make any effort to ensure that it leaves the pipeline in a sensible state, which is pretty awkward. In particular, there are 3 things the pipeline handler may be holding on to that can lead to damage. The first is pipelined requests: if there are any, they should be delivered, as the user may be deliberately allowing pipelining. The second thing is read() calls. The HTTPServerPipelineHandler exerts backpressure on clients that aggressively pipeline by refusing to read from the socket. If that happens, and then the handler is removed from the channel, it will "forget" to restart reading from the socket on the way out. That leaves the channel quietly in a state where no reads will occur ever again, which is pretty uncool. The third thing is quiescing. The HTTPServerPipelineHandler catches quiescing events and allows them to deliver a response before closing a connection. If that has happened when the pipeline handler is removed, it should fall back to the behaviour as though it were not there. Modifications: - Added a handlerRemoved implementation to play event state that should be replayed. - Added a channelInactive implementation to drop data. Result: More graceful handler removal.