dnrops
/
swift-nio
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
swift-nio/Package.swift

148 lines
7.4 KiB
Swift
Raw Normal View History

initial adoption of DocC based documentaiton (#2235) * initial adoption of DocC based documentaiton motivation: use DocC for docs change: * add DocC catalog to NIO target, as the "landing page" * remove jazzy doc generation script * add Package.swift with tools-version 5.6 so that DocC can be used, and add a dependency on the DocC plugin * udpate soundness script * * add packge.swift files for older vrsions * adjust waning-as-error and enable-test-discovery to the different permutations * fixup * remove jazzy Co-authored-by: Cory Benfield <lukasa@apple.com>
2022-08-08 18:55:18 +08:00
// swift-tools-version:5.6
initial commit
2017-04-20 19:13:14 +08:00
//===----------------------------------------------------------------------===//
//
// This source file is part of the SwiftNIO open source project
//
Extract PriorityQueue to its own module. (#1932) Motivation: I'd like to move EmbeddedChannel and friends out of the main NIO repository and into their own module. Unfortunately, EmbeddedChannel shares the PriorityQueue implementation we wrote with the various POSIX channels. To avoid duplicating the code, we should pull it out to its own module. However, we've never wanted to commit to the API of this data structure, and the same is true now. To that end, I'm pulling it into an underscored module that is not a product of the package. We could have used the `@_spi` annotation here but honestly I'm a bit nervous about doing that at the low-level of NIO itself, as if the Swift team does change the spelling of it at any point in the future we'll be in real trouble. This way works almost as well, and makes our intent a lot clearer. Modifications: - Extracted Heap and PriorityQueue to a new module. - Made everything @inlinable to do our best to make performance acceptable. Result: We can re-use PriorityQueue.
2021-08-09 18:00:03 +08:00
// Copyright (c) 2017-2021 Apple Inc. and the SwiftNIO project authors
initial commit
2017-04-20 19:13:14 +08:00
// Licensed under Apache License v2.0
//
// See LICENSE.txt for license information
// See CONTRIBUTORS.txt for the list of SwiftNIO project authors
//
// SPDX-License-Identifier: Apache-2.0
//
//===----------------------------------------------------------------------===//
import PackageDescription
Deprecate `NIOAtomics` in favor of `Atomics` (#2204) Co-authored-by: Cory Benfield <lukasa@apple.com>
2022-07-01 17:31:14 +08:00
let swiftAtomics: PackageDescription.Target.Dependency = .product(name: "Atomics", package: "swift-atomics")
Implement a back-pressure aware `AsyncSequence` source (#2230) * Implement a back-pressure aware `AsyncSequence` source # Motivation We ran into multiple use-cases (https://github.com/apple/swift-nio/pull/2067, https://github.com/grpc/grpc-swift/blob/main/Sources/GRPC/AsyncAwaitSupport/PassthroughMessageSource.swift) already where we want to vend an `AsyncSequence` where elements are produced from the sync world while the consumer is in the async world. Furthermore, we need the `AsyncSequence` to properly support back-pressure. Since we already identified that this is something fundamental for our ecosystem and that current `AsyncSequence` sources are not providing the proper semantics or performance, it would be great to find a single solution that we can use everywhere. Before diving into the code, I think it is good to understand the goals of this `AsyncSequence`: - The `AsyncSequence` should support a single unicast `Subscriber` - The `AsyncSequence` should allow a pluggable back-pressure strategy - The `AsyncSequence` should allow to yield a sequence of elements to avoid aquiring the lock for every element. - We should make sure to do as few thread hops as possible to signal the producer to demand more elements. # Modification This PR introduces a new `AsyncSequence` called `NIOBackPressuredAsyncSequence`. The goal of that sequence to enable sync to async element streaming with back-pressure support. # Result We can now power our sync to async use-cases with this new `AsyncSequence`. # Future work There are couple of things left that I wanna land in a follow up PR: 1. An adaptive back-pressure strategy that grows and shrinks depending on the speed of consumption 2. A throwing version of this sequence 3. Potentially an async version that suspends on `yield()` and resumes when more elements should be demanded. * Fix cancellation handling * Review * Add init helper * Add return types to help the type checker * Fix 5.7 CI * Rename delegate method and update docs * Review * Switch to Deque, rename the type and change the behaviour of yielding an empty sequence * Review comments from George * Review comments by Konrad * Review and add tests for the high low strategy * Fix 5.4 tests * Code review Co-authored-by: Cory Benfield <lukasa@apple.com>
2022-08-04 22:58:28 +08:00
let swiftCollections: PackageDescription.Target.Dependency = .product(name: "DequeModule", package: "swift-collections")
Deprecate `NIOAtomics` in favor of `Atomics` (#2204) Co-authored-by: Cory Benfield <lukasa@apple.com>
2022-07-01 17:31:14 +08:00
initial commit
2017-04-20 19:13:14 +08:00
var targets: [PackageDescription.Target] = [
Extract basic data structures to NIOCore. (#1895) Motivation: Currently the "core" NIO module (currently called NIO) contains two fairly distinct kinds of things. The first is the core abstractions and data structures: the things that all NIO programs must necessarily deal with. This includes our base abstraction protocols (e.g. `EventLoop`, `Channel`, and `ChannelHandler`), as well as our base data types (e.g. `ByteBuffer`, `SocketAddress`, `EventLoopFuture`). The second thing the core NIO module contains is the default POSIX sockets event-loop and channels. These are the mainline production loops for NIO programs, and are supported in the various BSD-like OSes to varying extents. These can be thought of as a baseline implementation of the core abstraction protocols that form the first part of NIO. These two fairly distinct use-cases have no particular reason to be glued together, and in fact in gluing them together we have done a bit of a disservice to our adopters. The biggest issue is that it has become impossible to write a NIO program or library that does not bring along the POSIX layer of NIO. This has made porting NIO to other platforms difficult (Windows has been painful, and Webassembly is coming down the road as well), and has also bloated the size of iOS/macOS applications that use NIO via NIOTransportServices, as all of these applications must bring along an event loop and several Channels they will not use. To that end, we plan to begin a scope of work to split the core NIO module in two. Specifically, we intend to extract the baseline protocols and data types into a new module, called `NIOCore`, which will be able to be the baseline NIO module. The end goal is that libraries that implement protocols on top of SwiftNIO should be able to depend solely on `NIOCore`, not `NIO`. This will allow NIO applications to bring along only the event loops they want or need, without needing to pay for the POSIX sockets implementation. This should also make porting easier, as there will be no pressure to bring the existing `NIO` module to new platforms if it does not fit well. Modifications: This is the first in a series of patches, which extracts some of the low-hanging fruit. In particular, it extracts: - `ByteBuffer` (and associated types) - `RecvByteBufferAllocator` - `CircularBuffer` This also adds in the backwards compatibility shim: the `NIO` package performs an exported import of `NIOCore`. This will allow this change to avoid breaking API. However, to make a clean break we intend not to release a new NIO minor version until we have completed our extraction. If we fail to do this it won't be the end of the world, we can release subsequent minor versions that continue to extract new types. However, as much as possible should go at once. This patch also duplicates a few methods and files. At the end of the patch series we need to reconcile this duplication. In many cases the duplication will no longer be necessary, but in some cases we may have necessary duplicates. Result: The first step along the road to better platform citizenship is taken.
2021-07-14 16:58:25 +08:00
.target(name: "NIOCore",
Implement a `NIOAsyncWriter` (#2251) * Implement a `NIOAsyncWriter` # Motivation We previously added the `NIOAsyncProducer` to bridge between the NIO channel pipeline and the asynchronous world. However, we still need something to bridge writes from the asynchronous world back to the NIO channel pipeline. # Modification This PR adds a new `NIOAsyncWriter` type that allows us to asynchronously `yield` elements to it. On the other side, we can register a `NIOAsyncWriterDelegate` which will get informed about any written elements. Furthermore, the synchronous side can toggle the writability of the `AsyncWriter` which allows it to implement flow control. A main goal of this type is to be as performant as possible. To achieve this I did the following things: - Make everything generic and inlinable - Use a class with a lock instead of an actor - Provide methods to yield a sequence of things which allows users to reduce the amount of times the lock gets acquired. # Result We now have the means to bridge writes from the asynchronous world to the synchronous * Remove the completion struct and incorporate code review comments * Fixup some refactoring leftovers * More code review comments * Move to holding the lock around the delegate and moved the delegate into the state machine * Comment fixups * More doc fixes * Call finish when the sink deinits * Refactor the writer to only yield Deques and rename the delegate to NIOAsyncWriterSinkDelegate * Review * Fix some warnings * Fix benchmark sendability * Remove Failure generic parameter and allow sending of an error through the Sink
2022-09-21 17:53:53 +08:00
dependencies: ["NIOConcurrencyHelpers", "CNIOLinux", "CNIOWindows", swiftCollections, swiftAtomics]),
Extract PriorityQueue to its own module. (#1932) Motivation: I'd like to move EmbeddedChannel and friends out of the main NIO repository and into their own module. Unfortunately, EmbeddedChannel shares the PriorityQueue implementation we wrote with the various POSIX channels. To avoid duplicating the code, we should pull it out to its own module. However, we've never wanted to commit to the API of this data structure, and the same is true now. To that end, I'm pulling it into an underscored module that is not a product of the package. We could have used the `@_spi` annotation here but honestly I'm a bit nervous about doing that at the low-level of NIO itself, as if the Swift team does change the spelling of it at any point in the future we'll be in real trouble. This way works almost as well, and makes our intent a lot clearer. Modifications: - Extracted Heap and PriorityQueue to a new module. - Made everything @inlinable to do our best to make performance acceptable. Result: We can re-use PriorityQueue.
2021-08-09 18:00:03 +08:00
.target(name: "_NIODataStructures"),
Define AsyncEmbeddedEventLoop (#2083) Motivation The rise of Swift concurrency has meant that a number of our APIs need to be recontextualised as async/await capable. While generally this is a straightforward task, any time those APIs were tested using EmbeddedChannel we have a testing issue. Swift Concurrency requires the use of its own cooperative thread pool, which is completely incapable of safely interoperating with EmbeddedChannel and EmbeddedEventLoop. This is becuase those two types "embed" into the current thread and are not thread-safe, but our concurrency-focused APIs want to enable users to use them from any Task. To that end we need to develop new types that serve the needs of EmbeddedChannel and EmbeddedEventLoop (control over I/O and task scheduling) while remaining fully thread-safe. This is the first of a series of patches that adds this functionality, starting with the AsyncEmbeddedEventLoop. Modifications - Define AsyncEmbeddedEventLoop Result A required building block for AsyncEmbeddedChannel exists. Co-authored-by: Franz Busch <privat@franz-busch.de>
2022-05-05 00:03:03 +08:00
.target(name: "NIOEmbedded",
dependencies: ["NIOCore",
"NIOConcurrencyHelpers",
Deprecate `NIOAtomics` in favor of `Atomics` (#2204) Co-authored-by: Cory Benfield <lukasa@apple.com>
2022-07-01 17:31:14 +08:00
"_NIODataStructures",
Add `NIOAsyncTestingChannel.waitForOut/InboundWrite()` (#2307)
2022-11-08 19:45:24 +08:00
swiftAtomics,
swiftCollections]),
Move NIO to NIOPosix, make NIO a shell. (#1936) Motivation: The remaining NIO code really conceptually belongs in a module called NIOPosix, and NIOCore should really be called NIO. We can't really do that last step, but we can prepare by pushing the bulk of the remaining code into a module called NIOPosix. Modifications: - Move NIO to NIOPosix - Make NIO an umbrella module. Result: NIOPosix exists.
2021-08-16 23:50:40 +08:00
.target(name: "NIOPosix",
initial commit
2017-04-20 19:13:14 +08:00
dependencies: ["CNIOLinux",
"CNIODarwin",
build: add `CNIOWindows` to Package.swift (#1638) This adds the CNIOWindows module to the package definition which is needed for Windows. Co-authored-by: Cory Benfield <lukasa@apple.com>
2020-09-22 01:03:41 +08:00
"CNIOWindows",
Extract basic data structures to NIOCore. (#1895) Motivation: Currently the "core" NIO module (currently called NIO) contains two fairly distinct kinds of things. The first is the core abstractions and data structures: the things that all NIO programs must necessarily deal with. This includes our base abstraction protocols (e.g. `EventLoop`, `Channel`, and `ChannelHandler`), as well as our base data types (e.g. `ByteBuffer`, `SocketAddress`, `EventLoopFuture`). The second thing the core NIO module contains is the default POSIX sockets event-loop and channels. These are the mainline production loops for NIO programs, and are supported in the various BSD-like OSes to varying extents. These can be thought of as a baseline implementation of the core abstraction protocols that form the first part of NIO. These two fairly distinct use-cases have no particular reason to be glued together, and in fact in gluing them together we have done a bit of a disservice to our adopters. The biggest issue is that it has become impossible to write a NIO program or library that does not bring along the POSIX layer of NIO. This has made porting NIO to other platforms difficult (Windows has been painful, and Webassembly is coming down the road as well), and has also bloated the size of iOS/macOS applications that use NIO via NIOTransportServices, as all of these applications must bring along an event loop and several Channels they will not use. To that end, we plan to begin a scope of work to split the core NIO module in two. Specifically, we intend to extract the baseline protocols and data types into a new module, called `NIOCore`, which will be able to be the baseline NIO module. The end goal is that libraries that implement protocols on top of SwiftNIO should be able to depend solely on `NIOCore`, not `NIO`. This will allow NIO applications to bring along only the event loops they want or need, without needing to pay for the POSIX sockets implementation. This should also make porting easier, as there will be no pressure to bring the existing `NIO` module to new platforms if it does not fit well. Modifications: This is the first in a series of patches, which extracts some of the low-hanging fruit. In particular, it extracts: - `ByteBuffer` (and associated types) - `RecvByteBufferAllocator` - `CircularBuffer` This also adds in the backwards compatibility shim: the `NIO` package performs an exported import of `NIOCore`. This will allow this change to avoid breaking API. However, to make a clean break we intend not to release a new NIO minor version until we have completed our extraction. If we fail to do this it won't be the end of the world, we can release subsequent minor versions that continue to extract new types. However, as much as possible should go at once. This patch also duplicates a few methods and files. At the end of the patch series we need to reconcile this duplication. In many cases the duplication will no longer be necessary, but in some cases we may have necessary duplicates. Result: The first step along the road to better platform citizenship is taken.
2021-07-14 16:58:25 +08:00
"NIOConcurrencyHelpers",
Extract PriorityQueue to its own module. (#1932) Motivation: I'd like to move EmbeddedChannel and friends out of the main NIO repository and into their own module. Unfortunately, EmbeddedChannel shares the PriorityQueue implementation we wrote with the various POSIX channels. To avoid duplicating the code, we should pull it out to its own module. However, we've never wanted to commit to the API of this data structure, and the same is true now. To that end, I'm pulling it into an underscored module that is not a product of the package. We could have used the `@_spi` annotation here but honestly I'm a bit nervous about doing that at the low-level of NIO itself, as if the Swift team does change the spelling of it at any point in the future we'll be in real trouble. This way works almost as well, and makes our intent a lot clearer. Modifications: - Extracted Heap and PriorityQueue to a new module. - Made everything @inlinable to do our best to make performance acceptable. Result: We can re-use PriorityQueue.
2021-08-09 18:00:03 +08:00
"NIOCore",
Deprecate `NIOAtomics` in favor of `Atomics` (#2204) Co-authored-by: Cory Benfield <lukasa@apple.com>
2022-07-01 17:31:14 +08:00
"_NIODataStructures",
swiftAtomics]),
Move NIO to NIOPosix, make NIO a shell. (#1936) Motivation: The remaining NIO code really conceptually belongs in a module called NIOPosix, and NIOCore should really be called NIO. We can't really do that last step, but we can prepare by pushing the bulk of the remaining code into a module called NIOPosix. Modifications: - Move NIO to NIOPosix - Make NIO an umbrella module. Result: NIOPosix exists.
2021-08-16 23:50:40 +08:00
.target(name: "NIO",
dependencies: ["NIOCore",
"NIOEmbedded",
"NIOPosix"]),
Readd module _NIOConcurrency to not break adopters (#1970)
2021-09-23 22:50:53 +08:00
.target(name: "_NIOConcurrency",
dependencies: ["NIO", "NIOCore"]),
Re-add NIO as a dependency of our library targets. (#1937) Motivation: In #1935 I removed NIO as a dependency of a number of our library targets. This unfortunately led to some downstream breakage in modules that were (incorrectly) assuming they could import NIO without expressing a dependency on it in their Package.swift, e.g. swift-server/swift-aws-lambda-runtime#218. While a forums thread (https://forums.swift.org/t/semantic-versioning-should-removing-a-dependency-be-a-semver-major/51179) is ongoing to discuss the implications of this, we should re-add the dependency to undo the breakage against main. I've validated this locally: merely having the dependency is enough, we don't have to use it. Modifications: - Re-add NIO as a dependency to: - _NIOConcurrency - NIOFoundationCompat - NIOHTTP1 - NIOTLS - NIOWebSocket Result: Broken downstreams can build again.
2021-08-16 17:07:27 +08:00
.target(name: "NIOFoundationCompat", dependencies: ["NIO", "NIOCore"]),
Add initial websocket codec. (#109) Motivation: Websockets is a major protocol in use on the web today, and is particularly valuable in applications that use asynchronous I/O as it allows servers to keep connections open for long periods of time for fully-duplex communication. Users of NIO should be able to build websocket clients and servers without too much difficulty. Modifications: Provided a WebsocketFrameEncoder and Decoder that can serialize and deserialize Websocket frames. Result: Easier use of websockets.
2018-03-14 00:24:54 +08:00
.target(name: "CNIOAtomics", dependencies: []),
.target(name: "CNIOSHA1", dependencies: []),
initial commit
2017-04-20 19:13:14 +08:00
.target(name: "CNIOLinux", dependencies: []),
Feature: Datagram Packet Info (#1888) * Break out control message parsing by IP version * Add shims for Darwin packet info * Add shims for Linux packet info * Add channel option for receiving datagram packet info * Add NIOPacketInfo to AddressedEnvelope.Metadata * Pipe up packet info channel option to receive path * Add NIOPacketInfo info and fix backwards compatability * Document packet info socket options * Cleanup packet info control message parsing * Add packet info and ECN combined tests * Find real interface index during NIOPacketInfo tests * Add PacketInfo tests to Linux tests
2021-07-08 18:04:53 +08:00
.target(name: "CNIODarwin", dependencies: [], cSettings: [.define("__APPLE_USE_RFC_3542")]),
build: add `CNIOWindows` to Package.swift (#1638) This adds the CNIOWindows module to the package definition which is needed for Windows. Co-authored-by: Cory Benfield <lukasa@apple.com>
2020-09-22 01:03:41 +08:00
.target(name: "CNIOWindows", dependencies: []),
initial commit
2017-04-20 19:13:14 +08:00
.target(name: "NIOConcurrencyHelpers",
dependencies: ["CNIOAtomics"]),
.target(name: "NIOHTTP1",
Update HTTP parser to LLHTTP (#2263) Motivation: The node.js HTTP parser library that we use has been unmaintained for some time. We should move to the maintained replacement, which is llhttp. This patch will update our dependency and bring us over to the new library, as well as make any changes we need. Modifications: This patch comes in 4 parts, each contained in a separate commit in the PR. The first commit drops the existing http_parser code and updates some of the repo state for using llhttp. The second commit rewrites the update script to bring in llhttp instead of http_parser. The third runs the actual script. You can skip reviewing this except to sanity check the outcome. The fourth commit updates the NIO code and the tests to get everything working. In general the substance of the product modifications was minimal. The logic around keeping track of where we are in the buffer and how upgrades work has changed a bit, so that required some fiddling. I also had to add an error reporting path for the delegates to be able to throw specific errors that llhttp no longer checks for. Finally, I removed two tests that were a little overzealous and that llhttp does not police. Result: Back on the supported path.
2022-09-13 21:09:57 +08:00
dependencies: ["NIO", "NIOCore", "NIOConcurrencyHelpers", "CNIOLLHTTP"]),
Fix warnings, that appeared after requiring Swift 5.4 (#2085)
2022-04-22 00:12:01 +08:00
.executableTarget(name: "NIOEchoServer",
dependencies: ["NIOPosix", "NIOCore", "NIOConcurrencyHelpers"],
exclude: ["README.md"]),
.executableTarget(name: "NIOEchoClient",
dependencies: ["NIOPosix", "NIOCore", "NIOConcurrencyHelpers"],
exclude: ["README.md"]),
.executableTarget(name: "NIOHTTP1Server",
dependencies: ["NIOPosix", "NIOCore", "NIOHTTP1", "NIOConcurrencyHelpers"],
exclude: ["README.md"]),
.executableTarget(name: "NIOHTTP1Client",
dependencies: ["NIOPosix", "NIOCore", "NIOHTTP1", "NIOConcurrencyHelpers"],
exclude: ["README.md"]),
Merge pull request from GHSA-7fj7-39wj-c64f Motivation HTTP headers are prevented from containing certain characters that can potentially affect parsing or interpretation. Inadequately policing this can lead to vulnerabilities in web applications, most notably HTTP Response Splitting. NIO was insufficiently policing the correctness of the header fields we emit in HTTP/1.1. We've therefore added a new handler that is automatically added to channel pipelines that will police the validity of header fields. For projects that are already running the validation themselves, this can be easily disabled. Note that by default NIO does not validate content length is correctly calculated, so applications can have their framing fall out of sync unless they appropriately calculate this themselves or use chunked transfer encoding. Modifications - Add thorough unit testing to confirm we will not emit invalid header fields. - Error if a user attempts to send an invalid header field. Result NIO applications are no longer vulnerable to response splitting by CRLF injection by default.
2022-09-27 20:09:52 +08:00
.target(
name: "CNIOLLHTTP",
cSettings: [.define("LLHTTP_STRICT_MODE")]
),
Re-add NIO as a dependency of our library targets. (#1937) Motivation: In #1935 I removed NIO as a dependency of a number of our library targets. This unfortunately led to some downstream breakage in modules that were (incorrectly) assuming they could import NIO without expressing a dependency on it in their Package.swift, e.g. swift-server/swift-aws-lambda-runtime#218. While a forums thread (https://forums.swift.org/t/semantic-versioning-should-removing-a-dependency-be-a-semver-major/51179) is ongoing to discuss the implications of this, we should re-add the dependency to undo the breakage against main. I've validated this locally: merely having the dependency is enough, we don't have to use it. Modifications: - Re-add NIO as a dependency to: - _NIOConcurrency - NIOFoundationCompat - NIOHTTP1 - NIOTLS - NIOWebSocket Result: Broken downstreams can build again.
2021-08-16 17:07:27 +08:00
.target(name: "NIOTLS", dependencies: ["NIO", "NIOCore"]),
Fix warnings, that appeared after requiring Swift 5.4 (#2085)
2022-04-22 00:12:01 +08:00
.executableTarget(name: "NIOChatServer",
dependencies: ["NIOPosix", "NIOCore", "NIOConcurrencyHelpers"],
exclude: ["README.md"]),
.executableTarget(name: "NIOChatClient",
dependencies: ["NIOPosix", "NIOCore", "NIOConcurrencyHelpers"],
exclude: ["README.md"]),
Add initial websocket codec. (#109) Motivation: Websockets is a major protocol in use on the web today, and is particularly valuable in applications that use asynchronous I/O as it allows servers to keep connections open for long periods of time for fully-duplex communication. Users of NIO should be able to build websocket clients and servers without too much difficulty. Modifications: Provided a WebsocketFrameEncoder and Decoder that can serialize and deserialize Websocket frames. Result: Easier use of websockets.
2018-03-14 00:24:54 +08:00
.target(name: "NIOWebSocket",
Re-add NIO as a dependency of our library targets. (#1937) Motivation: In #1935 I removed NIO as a dependency of a number of our library targets. This unfortunately led to some downstream breakage in modules that were (incorrectly) assuming they could import NIO without expressing a dependency on it in their Package.swift, e.g. swift-server/swift-aws-lambda-runtime#218. While a forums thread (https://forums.swift.org/t/semantic-versioning-should-removing-a-dependency-be-a-semver-major/51179) is ongoing to discuss the implications of this, we should re-add the dependency to undo the breakage against main. I've validated this locally: merely having the dependency is enough, we don't have to use it. Modifications: - Re-add NIO as a dependency to: - _NIOConcurrency - NIOFoundationCompat - NIOHTTP1 - NIOTLS - NIOWebSocket Result: Broken downstreams can build again.
2021-08-16 17:07:27 +08:00
dependencies: ["NIO", "NIOCore", "NIOHTTP1", "CNIOSHA1"]),
Fix warnings, that appeared after requiring Swift 5.4 (#2085)
2022-04-22 00:12:01 +08:00
.executableTarget(name: "NIOWebSocketServer",
dependencies: ["NIOPosix", "NIOCore", "NIOHTTP1", "NIOWebSocket"],
exclude: ["README.md"]),
.executableTarget(name: "NIOWebSocketClient",
dependencies: ["NIOPosix", "NIOCore", "NIOHTTP1", "NIOWebSocket"],
exclude: ["README.md"]),
.executableTarget(name: "NIOPerformanceTester",
Move NIO to NIOPosix, make NIO a shell. (#1936) Motivation: The remaining NIO code really conceptually belongs in a module called NIOPosix, and NIOCore should really be called NIO. We can't really do that last step, but we can prepare by pushing the bulk of the remaining code into a module called NIOPosix. Modifications: - Move NIO to NIOPosix - Make NIO an umbrella module. Result: NIOPosix exists.
2021-08-16 23:50:40 +08:00
dependencies: ["NIOPosix", "NIOCore", "NIOEmbedded", "NIOHTTP1", "NIOFoundationCompat", "NIOWebSocket"]),
Fix warnings, that appeared after requiring Swift 5.4 (#2085)
2022-04-22 00:12:01 +08:00
.executableTarget(name: "NIOMulticastChat",
Move NIO to NIOPosix, make NIO a shell. (#1936) Motivation: The remaining NIO code really conceptually belongs in a module called NIOPosix, and NIOCore should really be called NIO. We can't really do that last step, but we can prepare by pushing the bulk of the remaining code into a module called NIOPosix. Modifications: - Move NIO to NIOPosix - Make NIO an umbrella module. Result: NIOPosix exists.
2021-08-16 23:50:40 +08:00
dependencies: ["NIOPosix", "NIOCore"]),
Fix warnings, that appeared after requiring Swift 5.4 (#2085)
2022-04-22 00:12:01 +08:00
.executableTarget(name: "NIOUDPEchoServer",
dependencies: ["NIOPosix", "NIOCore"],
exclude: ["README.md"]),
.executableTarget(name: "NIOUDPEchoClient",
dependencies: ["NIOPosix", "NIOCore"],
exclude: ["README.md"]),
Create NIOTestUtils & add B2MD verifier (#939) Motivation: When writing B2MDs, there are a couple of scenarios that always need to be tested: firehose feeding, drip feeding, many messages, ... It's tedious writing those tests over and over again for every B2MD. Modifications: - Add a simple B2MD verifier that users can use in unit tests. - Add a new, public `NIOTestUtils` module which contains utilities mostly useful for testing. Crucially however, it does not depend on `XCTest` so it can be used it all targets. Result: Hopefully fewer bugs in B2MDs.
2019-05-11 00:29:13 +08:00
.target(name: "NIOTestUtils",
Deprecate `NIOAtomics` in favor of `Atomics` (#2204) Co-authored-by: Cory Benfield <lukasa@apple.com>
2022-07-01 17:31:14 +08:00
dependencies: ["NIOPosix", "NIOCore", "NIOEmbedded", "NIOHTTP1", swiftAtomics]),
Fix warnings, that appeared after requiring Swift 5.4 (#2085)
2022-04-22 00:12:01 +08:00
.executableTarget(name: "NIOCrashTester",
Move NIO to NIOPosix, make NIO a shell. (#1936) Motivation: The remaining NIO code really conceptually belongs in a module called NIOPosix, and NIOCore should really be called NIO. We can't really do that last step, but we can prepare by pushing the bulk of the remaining code into a module called NIOPosix. Modifications: - Move NIO to NIOPosix - Make NIO an umbrella module. Result: NIOPosix exists.
2021-08-16 23:50:40 +08:00
dependencies: ["NIOPosix", "NIOCore", "NIOEmbedded", "NIOHTTP1", "NIOWebSocket", "NIOFoundationCompat"]),
Fix warnings, that appeared after requiring Swift 5.4 (#2085)
2022-04-22 00:12:01 +08:00
.executableTarget(name: "NIOAsyncAwaitDemo",
Move AsyncAwait helpers into NIOCore (#1969) - Moved the `AsyncAwaitSupport.swift` to `NIOCore` - Removed the `_NIOConcurrency` target
2021-09-23 20:14:49 +08:00
dependencies: ["NIOPosix", "NIOCore", "NIOHTTP1"]),
Conform `AddressedEnvelope` conditionally to `Hashable` & `Equatable` (#2017) ### Motivation: Sometimes, it is nice to check `AddressedEnvelope`s for equality or hash them. Especially, in tests this comes in handy. ### Modifications: This PR, adds conditional conformances to `AddressedEnvelope` for `Equatable` and `Hashable` depending on its generic `DataType` . I also added a new module `NIOCoreTests` which was an open todoleft from the creation of the `NIOCore` module. To not add more tests that we have to migrate in the future, I started to create the new tests in the new module right away. I also created issue https://github.com/apple/swift-nio/issues/2016, to keep track of our open task to move the other tests over. ### Result: `AddressedEnvelope` is conditionally `Equatable` and `Hashable`
2021-12-21 02:22:13 +08:00
.testTarget(name: "NIOCoreTests",
Move tests of NIOCore types from NIOPosixTests to NIOCoreTests (#2093) * Move tests of NIOCore types from NIOPosixTests to NIOCoreTests * fixup: LinuxTest Signed-off-by: Si Beaumont <beaumont@apple.com> * fixup: Port some test utils to not use NIOPosix Signed-off-by: Si Beaumont <beaumont@apple.com> * fixup: No swift-system, duh Signed-off-by: Si Beaumont <beaumont@apple.com> * fixup: read-write for temporary file in test helper Signed-off-by: Si Beaumont <beaumont@apple.com> Co-authored-by: Cory Benfield <lukasa@apple.com>
2022-05-04 23:14:18 +08:00
dependencies: ["NIOCore", "NIOEmbedded", "NIOFoundationCompat"]),
Move EmbeddedChannel to its own library. (#1933) Motivation: EmbeddedChannel is an important testing tool, and we want to use it without needing to bring along the POSIX layer. They are not tightly coupled. However, it also doesn't belong naturally in NIOCore, so we should probably put it in its own place. Modifications: - Moved EmbeddedChannel and EmbeddedEventLoop to NIOEmbedded. - Moved the tests to NIOEmbeddedTests - Duplicated some test helpers Result: Easy to use EmbeddedChannel without the POSIX layer.
2021-08-11 17:50:32 +08:00
.testTarget(name: "NIOEmbeddedTests",
dependencies: ["NIOConcurrencyHelpers", "NIOCore", "NIOEmbedded"]),
Move NIO to NIOPosix, make NIO a shell. (#1936) Motivation: The remaining NIO code really conceptually belongs in a module called NIOPosix, and NIOCore should really be called NIO. We can't really do that last step, but we can prepare by pushing the bulk of the remaining code into a module called NIOPosix. Modifications: - Move NIO to NIOPosix - Make NIO an umbrella module. Result: NIOPosix exists.
2021-08-16 23:50:40 +08:00
.testTarget(name: "NIOPosixTests",
Allow UDP GRO tests to fail in some circumstances (#2387) Motivation: The recently added UDP GRO tests fail on some older Linux Kernel versions. We believe that UDP GRO support on loopback was limited in early versions so we should tolerate those failures. However, we've verified that on 5.15 and newer that GRO is supported so we should not tolerate failure in those cases. Modifications: - Add shims to CNIOLinux to get system info via uname - Verify GRO works before running GRO tests and if it doesn't then validate the kernel version isn't greater than 5.15. Results: Less flaky tests.
2023-03-13 19:12:06 +08:00
dependencies: ["NIOPosix", "NIOCore", "NIOFoundationCompat", "NIOTestUtils", "NIOConcurrencyHelpers", "NIOEmbedded", "CNIOLinux"]),
initial commit
2017-04-20 19:13:14 +08:00
.testTarget(name: "NIOConcurrencyHelpersTests",
Clean up dependencies and imports. (#1935) Motivation: As we've largely completed our move to split out our core abstractions, we now have an opportunity to clean up our dependencies and imports. We should arrange for everything to only import NIO if it actually needs it, and to correctly express dependencies on NIOCore and NIOEmbedded where they exist. We aren't yet splitting out tests that only test functionality in NIOCore, that will follow in a separate patch. Modifications: - Fixed up imports - Made sure our protocols only require NIOCore. Result: Better expression of dependencies. Co-authored-by: George Barnett <gbarnett@apple.com>
2021-08-12 20:49:46 +08:00
dependencies: ["NIOConcurrencyHelpers", "NIOCore"]),
Extract PriorityQueue to its own module. (#1932) Motivation: I'd like to move EmbeddedChannel and friends out of the main NIO repository and into their own module. Unfortunately, EmbeddedChannel shares the PriorityQueue implementation we wrote with the various POSIX channels. To avoid duplicating the code, we should pull it out to its own module. However, we've never wanted to commit to the API of this data structure, and the same is true now. To that end, I'm pulling it into an underscored module that is not a product of the package. We could have used the `@_spi` annotation here but honestly I'm a bit nervous about doing that at the low-level of NIO itself, as if the Swift team does change the spelling of it at any point in the future we'll be in real trouble. This way works almost as well, and makes our intent a lot clearer. Modifications: - Extracted Heap and PriorityQueue to a new module. - Made everything @inlinable to do our best to make performance acceptable. Result: We can re-use PriorityQueue.
2021-08-09 18:00:03 +08:00
.testTarget(name: "NIODataStructuresTests",
dependencies: ["_NIODataStructures"]),
initial commit
2017-04-20 19:13:14 +08:00
.testTarget(name: "NIOHTTP1Tests",
Move NIO to NIOPosix, make NIO a shell. (#1936) Motivation: The remaining NIO code really conceptually belongs in a module called NIOPosix, and NIOCore should really be called NIO. We can't really do that last step, but we can prepare by pushing the bulk of the remaining code into a module called NIOPosix. Modifications: - Move NIO to NIOPosix - Make NIO an umbrella module. Result: NIOPosix exists.
2021-08-16 23:50:40 +08:00
dependencies: ["NIOCore", "NIOEmbedded", "NIOPosix", "NIOHTTP1", "NIOFoundationCompat", "NIOTestUtils"]),
initial commit
2017-04-20 19:13:14 +08:00
.testTarget(name: "NIOTLSTests",
Clean up dependencies and imports. (#1935) Motivation: As we've largely completed our move to split out our core abstractions, we now have an opportunity to clean up our dependencies and imports. We should arrange for everything to only import NIO if it actually needs it, and to correctly express dependencies on NIOCore and NIOEmbedded where they exist. We aren't yet splitting out tests that only test functionality in NIOCore, that will follow in a separate patch. Modifications: - Fixed up imports - Made sure our protocols only require NIOCore. Result: Better expression of dependencies. Co-authored-by: George Barnett <gbarnett@apple.com>
2021-08-12 20:49:46 +08:00
dependencies: ["NIOCore", "NIOEmbedded", "NIOTLS", "NIOFoundationCompat"]),
Add initial websocket codec. (#109) Motivation: Websockets is a major protocol in use on the web today, and is particularly valuable in applications that use asynchronous I/O as it allows servers to keep connections open for long periods of time for fully-duplex communication. Users of NIO should be able to build websocket clients and servers without too much difficulty. Modifications: Provided a WebsocketFrameEncoder and Decoder that can serialize and deserialize Websocket frames. Result: Easier use of websockets.
2018-03-14 00:24:54 +08:00
.testTarget(name: "NIOWebSocketTests",
Clean up dependencies and imports. (#1935) Motivation: As we've largely completed our move to split out our core abstractions, we now have an opportunity to clean up our dependencies and imports. We should arrange for everything to only import NIO if it actually needs it, and to correctly express dependencies on NIOCore and NIOEmbedded where they exist. We aren't yet splitting out tests that only test functionality in NIOCore, that will follow in a separate patch. Modifications: - Fixed up imports - Made sure our protocols only require NIOCore. Result: Better expression of dependencies. Co-authored-by: George Barnett <gbarnett@apple.com>
2021-08-12 20:49:46 +08:00
dependencies: ["NIOCore", "NIOEmbedded", "NIOWebSocket"]),
Create NIOTestUtils & add B2MD verifier (#939) Motivation: When writing B2MDs, there are a couple of scenarios that always need to be tested: firehose feeding, drip feeding, many messages, ... It's tedious writing those tests over and over again for every B2MD. Modifications: - Add a simple B2MD verifier that users can use in unit tests. - Add a new, public `NIOTestUtils` module which contains utilities mostly useful for testing. Crucially however, it does not depend on `XCTest` so it can be used it all targets. Result: Hopefully fewer bugs in B2MDs.
2019-05-11 00:29:13 +08:00
.testTarget(name: "NIOTestUtilsTests",
Move NIO to NIOPosix, make NIO a shell. (#1936) Motivation: The remaining NIO code really conceptually belongs in a module called NIOPosix, and NIOCore should really be called NIO. We can't really do that last step, but we can prepare by pushing the bulk of the remaining code into a module called NIOPosix. Modifications: - Move NIO to NIOPosix - Make NIO an umbrella module. Result: NIOPosix exists.
2021-08-16 23:50:40 +08:00
dependencies: ["NIOTestUtils", "NIOCore", "NIOEmbedded", "NIOPosix"]),
ByteBuffer: add direct Codable support (#1153) Motivation: So far, it has been harder than necessary to use Codable & ByteBuffer. These new APIs should simplify that and allow future optimisations. Modifications: Add new API to use `JSONEncoder` and `JSONDecoder` directly with `ByteBuffer`. Result: Easier Codable + ByteBuffer usage.
2019-10-18 07:03:44 +08:00
.testTarget(name: "NIOFoundationCompatTests",
Clean up dependencies and imports. (#1935) Motivation: As we've largely completed our move to split out our core abstractions, we now have an opportunity to clean up our dependencies and imports. We should arrange for everything to only import NIO if it actually needs it, and to correctly express dependencies on NIOCore and NIOEmbedded where they exist. We aren't yet splitting out tests that only test functionality in NIOCore, that will follow in a separate patch. Modifications: - Fixed up imports - Made sure our protocols only require NIOCore. Result: Better expression of dependencies. Co-authored-by: George Barnett <gbarnett@apple.com>
2021-08-12 20:49:46 +08:00
dependencies: ["NIOCore", "NIOFoundationCompat"]),
Move NIO to NIOPosix, make NIO a shell. (#1936) Motivation: The remaining NIO code really conceptually belongs in a module called NIOPosix, and NIOCore should really be called NIO. We can't really do that last step, but we can prepare by pushing the bulk of the remaining code into a module called NIOPosix. Modifications: - Move NIO to NIOPosix - Make NIO an umbrella module. Result: NIOPosix exists.
2021-08-16 23:50:40 +08:00
.testTarget(name: "NIOTests",
dependencies: ["NIO"]),
initial commit
2017-04-20 19:13:14 +08:00
]
let package = Package(
name: "swift-nio",
products: [
Extract basic data structures to NIOCore. (#1895) Motivation: Currently the "core" NIO module (currently called NIO) contains two fairly distinct kinds of things. The first is the core abstractions and data structures: the things that all NIO programs must necessarily deal with. This includes our base abstraction protocols (e.g. `EventLoop`, `Channel`, and `ChannelHandler`), as well as our base data types (e.g. `ByteBuffer`, `SocketAddress`, `EventLoopFuture`). The second thing the core NIO module contains is the default POSIX sockets event-loop and channels. These are the mainline production loops for NIO programs, and are supported in the various BSD-like OSes to varying extents. These can be thought of as a baseline implementation of the core abstraction protocols that form the first part of NIO. These two fairly distinct use-cases have no particular reason to be glued together, and in fact in gluing them together we have done a bit of a disservice to our adopters. The biggest issue is that it has become impossible to write a NIO program or library that does not bring along the POSIX layer of NIO. This has made porting NIO to other platforms difficult (Windows has been painful, and Webassembly is coming down the road as well), and has also bloated the size of iOS/macOS applications that use NIO via NIOTransportServices, as all of these applications must bring along an event loop and several Channels they will not use. To that end, we plan to begin a scope of work to split the core NIO module in two. Specifically, we intend to extract the baseline protocols and data types into a new module, called `NIOCore`, which will be able to be the baseline NIO module. The end goal is that libraries that implement protocols on top of SwiftNIO should be able to depend solely on `NIOCore`, not `NIO`. This will allow NIO applications to bring along only the event loops they want or need, without needing to pay for the POSIX sockets implementation. This should also make porting easier, as there will be no pressure to bring the existing `NIO` module to new platforms if it does not fit well. Modifications: This is the first in a series of patches, which extracts some of the low-hanging fruit. In particular, it extracts: - `ByteBuffer` (and associated types) - `RecvByteBufferAllocator` - `CircularBuffer` This also adds in the backwards compatibility shim: the `NIO` package performs an exported import of `NIOCore`. This will allow this change to avoid breaking API. However, to make a clean break we intend not to release a new NIO minor version until we have completed our extraction. If we fail to do this it won't be the end of the world, we can release subsequent minor versions that continue to extract new types. However, as much as possible should go at once. This patch also duplicates a few methods and files. At the end of the patch series we need to reconcile this duplication. In many cases the duplication will no longer be necessary, but in some cases we may have necessary duplicates. Result: The first step along the road to better platform citizenship is taken.
2021-07-14 16:58:25 +08:00
.library(name: "NIOCore", targets: ["NIOCore"]),
initial commit
2017-04-20 19:13:14 +08:00
.library(name: "NIO", targets: ["NIO"]),
Move EmbeddedChannel to its own library. (#1933) Motivation: EmbeddedChannel is an important testing tool, and we want to use it without needing to bring along the POSIX layer. They are not tightly coupled. However, it also doesn't belong naturally in NIOCore, so we should probably put it in its own place. Modifications: - Moved EmbeddedChannel and EmbeddedEventLoop to NIOEmbedded. - Moved the tests to NIOEmbeddedTests - Duplicated some test helpers Result: Easy to use EmbeddedChannel without the POSIX layer.
2021-08-11 17:50:32 +08:00
.library(name: "NIOEmbedded", targets: ["NIOEmbedded"]),
Move NIO to NIOPosix, make NIO a shell. (#1936) Motivation: The remaining NIO code really conceptually belongs in a module called NIOPosix, and NIOCore should really be called NIO. We can't really do that last step, but we can prepare by pushing the bulk of the remaining code into a module called NIOPosix. Modifications: - Move NIO to NIOPosix - Make NIO an umbrella module. Result: NIOPosix exists.
2021-08-16 23:50:40 +08:00
.library(name: "NIOPosix", targets: ["NIOPosix"]),
Readd module _NIOConcurrency to not break adopters (#1970)
2021-09-23 22:50:53 +08:00
.library(name: "_NIOConcurrency", targets: ["_NIOConcurrency"]),
initial commit
2017-04-20 19:13:14 +08:00
.library(name: "NIOTLS", targets: ["NIOTLS"]),
.library(name: "NIOHTTP1", targets: ["NIOHTTP1"]),
.library(name: "NIOConcurrencyHelpers", targets: ["NIOConcurrencyHelpers"]),
add NIOFoundationCompat lib to package products (#57)
2018-03-02 09:52:07 +08:00
.library(name: "NIOFoundationCompat", targets: ["NIOFoundationCompat"]),
Add initial websocket codec. (#109) Motivation: Websockets is a major protocol in use on the web today, and is particularly valuable in applications that use asynchronous I/O as it allows servers to keep connections open for long periods of time for fully-duplex communication. Users of NIO should be able to build websocket clients and servers without too much difficulty. Modifications: Provided a WebsocketFrameEncoder and Decoder that can serialize and deserialize Websocket frames. Result: Easier use of websockets.
2018-03-14 00:24:54 +08:00
.library(name: "NIOWebSocket", targets: ["NIOWebSocket"]),
Create NIOTestUtils & add B2MD verifier (#939) Motivation: When writing B2MDs, there are a couple of scenarios that always need to be tested: firehose feeding, drip feeding, many messages, ... It's tedious writing those tests over and over again for every B2MD. Modifications: - Add a simple B2MD verifier that users can use in unit tests. - Add a new, public `NIOTestUtils` module which contains utilities mostly useful for testing. Crucially however, it does not depend on `XCTest` so it can be used it all targets. Result: Hopefully fewer bugs in B2MDs.
2019-05-11 00:29:13 +08:00
.library(name: "NIOTestUtils", targets: ["NIOTestUtils"]),
initial commit
2017-04-20 19:13:14 +08:00
],
dependencies: [
Deprecate `NIOAtomics` in favor of `Atomics` (#2204) Co-authored-by: Cory Benfield <lukasa@apple.com>
2022-07-01 17:31:14 +08:00
.package(url: "https://github.com/apple/swift-atomics.git", from: "1.0.2"),
Implement a back-pressure aware `AsyncSequence` source (#2230) * Implement a back-pressure aware `AsyncSequence` source # Motivation We ran into multiple use-cases (https://github.com/apple/swift-nio/pull/2067, https://github.com/grpc/grpc-swift/blob/main/Sources/GRPC/AsyncAwaitSupport/PassthroughMessageSource.swift) already where we want to vend an `AsyncSequence` where elements are produced from the sync world while the consumer is in the async world. Furthermore, we need the `AsyncSequence` to properly support back-pressure. Since we already identified that this is something fundamental for our ecosystem and that current `AsyncSequence` sources are not providing the proper semantics or performance, it would be great to find a single solution that we can use everywhere. Before diving into the code, I think it is good to understand the goals of this `AsyncSequence`: - The `AsyncSequence` should support a single unicast `Subscriber` - The `AsyncSequence` should allow a pluggable back-pressure strategy - The `AsyncSequence` should allow to yield a sequence of elements to avoid aquiring the lock for every element. - We should make sure to do as few thread hops as possible to signal the producer to demand more elements. # Modification This PR introduces a new `AsyncSequence` called `NIOBackPressuredAsyncSequence`. The goal of that sequence to enable sync to async element streaming with back-pressure support. # Result We can now power our sync to async use-cases with this new `AsyncSequence`. # Future work There are couple of things left that I wanna land in a follow up PR: 1. An adaptive back-pressure strategy that grows and shrinks depending on the speed of consumption 2. A throwing version of this sequence 3. Potentially an async version that suspends on `yield()` and resumes when more elements should be demanded. * Fix cancellation handling * Review * Add init helper * Add return types to help the type checker * Fix 5.7 CI * Rename delegate method and update docs * Review * Switch to Deque, rename the type and change the behaviour of yielding an empty sequence * Review comments from George * Review comments by Konrad * Review and add tests for the high low strategy * Fix 5.4 tests * Code review Co-authored-by: Cory Benfield <lukasa@apple.com>
2022-08-04 22:58:28 +08:00
.package(url: "https://github.com/apple/swift-collections.git", from: "1.0.2"),
initial adoption of DocC based documentaiton (#2235) * initial adoption of DocC based documentaiton motivation: use DocC for docs change: * add DocC catalog to NIO target, as the "landing page" * remove jazzy doc generation script * add Package.swift with tools-version 5.6 so that DocC can be used, and add a dependency on the DocC plugin * udpate soundness script * * add packge.swift files for older vrsions * adjust waning-as-error and enable-test-discovery to the different permutations * fixup * remove jazzy Co-authored-by: Cory Benfield <lukasa@apple.com>
2022-08-08 18:55:18 +08:00
.package(url: "https://github.com/apple/swift-docc-plugin", from: "1.0.0"),
initial commit
2017-04-20 19:13:14 +08:00
],
targets: targets
)