Tags: GeorgeLyon/swift-nio
Tags
Tests should tolerate cpusets. (apple#1853) Motivation: Our current CPU pinning tests do not expect to be pinned to cores that do not include core 0. That's unnecessary. Modifications: - Expect to pin to the first core in our cpuset. Result: Tests run inside cpusets.
Implement reserveCapacity for CircularBuffer. (apple#1819) Motivation: While spelunking through the code I noticed we called CircularBuffer.reserveCapacity, but never actually implemented it. This means it never did anything. It should do something. Modifications: - Implemented reserveCapacity. Result: reserveCapacity does something now.
Make HTTP Parser import implementationOnly (apple#1776) Motivation: Non-implementation-only imports in Swift have an annoying tendency to put C header files into all downstream build paths. The result is that leaf packages that include any C header files run a very high risk of colliding with declarations in the inner header files. In this case, we've had users bump into issues with the HTTP_STATUS_* enum cases already. Modifications: - Make CNIOHTTPParser import implementationOnly where possible. Result: Fewer risks of colliding symbols.
Make all imports of CNIOLinux conditional on OS (apple#1704) Motivation: Some users are including NIO in Xcode workspaces rather than using SPM. When this is done, if all imports of CNIOLinux are conditional they can remove this project from their workspace. Modifications: Make all imports of CNIOLinux conditional on Linux, Android or FreeBSD Result: No user visible change.
Remove use of removeAll(keepingCapacity:). (apple#1699) Motivation: As outlined in https://bugs.swift.org/browse/SR-13923, removeAll(keepingCapacity:) on Array has particularly negative performance when that Array is not uniquely referenced. In this case, in EmbeddedChannel, we _arrange_ to multiply reference it. This makes it swamp our HTTP/2 microbenchmarks, spending more cycles copying this buffer around than doing anything else. Modifications: - Just allocate a new buffer instead. Result: Much less copying.
Conform TimeAmount to AdditiveArithmetic (apple#1691) Conforms TimeAmount to AdditiveArithmetic. Motivation: TimeAmount does not support -=, +=. Sometimes it is useful to manipulate time amounts when building up a delay and if that iteration fails, we would want to delay += .milliseconds(5) to add 5 milliseconds to our delay and try again. Modifications: Conformed TimeAmount to AdditiveArithmetic: added a static zero property and required operators. Result: TimeAmount conforms to AdditiveArithmetic. Co-authored-by: Josh <jrtkski@icloud.com> Co-authored-by: Cory Benfield <lukasa@apple.com>
Minor cleanups of Windows compatability code. (apple#1663) Motivation: Cleanup some noise that came in with some previous Windows compat patches. Modifications: - Move INVALID_SOCKET to NIOBSDSocket, and refer to it by a better name there. - Comment in an empty block to indicate that it's supposed to be empty. Result: Bit cleaner code.
Note that certain NIOFileHandle.init overloads are blocking (apple#1630) This was noted in review of swift-server/async-http-client#275, but I don't think that this was clearly stated in the documentation.
Better handle writability changes in triggerWriteOperations (apple#1624) Motivation: If a write is buffered in the `PendingWritesManager` and the high watermark is breached then a writability change will be fired as a result. The corresponding event when the channel becomes writable again comes when enough pending bytes have been written to the socket (i.e. as a result of a `flush()`) and we fall below the low watermark. However, if a promise associated with a write has a callback registered on its future which writes enough data to breach the high watermark (and also flushes) then we will re-entrantly enter `flushNow()`. This is okay, `flushNow()` protects against re-entrancy and any re-entrantly enqueud flushed writes will be picked up in the write-spin-loop. The issue here is that the `writeSpinLoop` does not monitor for changes in writability. Instead if checks the writability before it begins and after it completes, only signalling if there was a change. This is problematic: the re-entrant write-and-flush could have caused the channel to become unwritable yet no event will be fired to make it writable again! Modifications: - Store a local writability state in the pending writes manager and modify it when we emit writability changes Result: - Better protection against re-entrant writability changes.
PreviousNext