apple/swift 56291
The Swift Programming Language
apple/swift-evolution 12446
This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
apple/swift-package-manager 8353
The Package Manager for the Swift Programming Language
apple/swift-corelibs-foundation 4293
The Foundation Project, providing core utilities, internationalization, and OS independence
apple/swift-corelibs-xctest 898
The XCTest Project, A Swift core library for providing unit test support
weissi/FRLayeredNavigationController 492
FRLayeredNavigationController, an iOS container view controller that works like a stack of paper with an API similar to UINavigationController.
An HTTP/2 APNS library built on swift-nio
swift-server/swift-backtrace 224
💥 Backtraces for Swift on Linux and Windows
swift-server/swift-service-lifecycle 223
Cleanly startup and shutdown server application, freeing resources in order before exiting.
Client side Prometheus library in Swift
Pull request review commentapple/swift-nio
Add async implementation of EventLoopGroup.shutdownGracefully to _NIOConcurrency
func main() async { print(", response:", String(buffer: response2.body ?? ByteBuffer())) try await channel.close()++ try await group.shutdownGracefully()
This patch isn't quite right as we now shut the loop down twice. Can you move the existing event loop construction out of the top-level scope and into this async function instead?
comment created time in 4 minutes
Pull request review commentapple/swift-nio
Add async implementation of EventLoopGroup.shutdownGracefully to _NIOConcurrency
extension EventLoopFuture { } } +extension EventLoopGroup {+ /// Shuts down the event loop gracefully.+ @available(macOS 12, iOS 15, tvOS 15, watchOS 8, *)+ @inlinable+ public func shutdownGracefully() async throws {+ return try await withCheckedThrowingContinuation { cont in+ self.shutdownGracefully { error in+ if let error = error {+ cont.resume(throwing: error)+ }+ cont.resume()
Continuations must be resumed exactly once: this will fail in the event we hit the error path, as we'll resume twice.
comment created time in 3 minutes
pull request commentapple/swift-nio
Add async implementation of EventLoopGroup.shutdownGracefully to _NIOConcurrency
Can one of the admins verify this patch?
comment created time in 6 minutes
pull request commentapple/swift-nio
Add async implementation of EventLoopGroup.shutdownGracefully to _NIOConcurrency
Can one of the admins verify this patch?
comment created time in 6 minutes
pull request commentapple/swift-nio
Add async implementation of EventLoopGroup.shutdownGracefully to _NIOConcurrency
Can one of the admins verify this patch?
comment created time in 6 minutes
pull request commentapple/swift-nio
Add async implementation of EventLoopGroup.shutdownGracefully to _NIOConcurrency
Can one of the admins verify this patch?
comment created time in 6 minutes
pull request commentapple/swift-nio
Add async implementation of EventLoopGroup.shutdownGracefully to _NIOConcurrency
Can one of the admins verify this patch?
comment created time in 6 minutes
pull request commentapple/swift-nio
Add async implementation of EventLoopGroup.shutdownGracefully to _NIOConcurrency
Can one of the admins verify this patch?
comment created time in 6 minutes
pull request commentapple/swift-nio
Add async implementation of EventLoopGroup.shutdownGracefully to _NIOConcurrency
Can one of the admins verify this patch?
comment created time in 6 minutes
pull request commentapple/swift-nio
Add async implementation of EventLoopGroup.shutdownGracefully to _NIOConcurrency
Can one of the admins verify this patch?
comment created time in 6 minutes
pull request commentapple/swift-nio
Add async implementation of EventLoopGroup.shutdownGracefully to _NIOConcurrency
Can one of the admins verify this patch?
comment created time in 6 minutes
pull request commentapple/swift-nio
Add async implementation of EventLoopGroup.shutdownGracefully to _NIOConcurrency
Can one of the admins verify this patch?
comment created time in 6 minutes
pull request commentapple/swift-nio
Add async implementation of EventLoopGroup.shutdownGracefully to _NIOConcurrency
Can one of the admins verify this patch?
comment created time in 6 minutes
pull request commentapple/swift-nio
Add async implementation of EventLoopGroup.shutdownGracefully to _NIOConcurrency
Can one of the admins verify this patch?
comment created time in 6 minutes
pull request commentapple/swift-nio
Add async implementation of EventLoopGroup.shutdownGracefully to _NIOConcurrency
Can one of the admins verify this patch?
comment created time in 6 minutes
pull request commentapple/swift-nio
Add async implementation of EventLoopGroup.shutdownGracefully to _NIOConcurrency
Can one of the admins verify this patch?
comment created time in 6 minutes
PR opened apple/swift-nio
Adds a new extension to EventLoopGroup in _NIOConcurrency to provide an asynchronous shutdownGracefully().
Motivation
Shutting down an event loop was special because it used a completion handler and executed on a DispatchQueue because there would be no event loop to use an EventLoopFuture.
Now we have the new Swift concurrency features, we can provide an async shutdownGracefully.
Fixes #1878.
Modifications
Adds EventLoopGroup.shutdownGracefully() async and some code to use it in NIOAsyncAwaitDemo.
There's no obvious way to ask an ELG if it has been shutdown but I made the following local-only changes to verify that this performs as expected:
diff --git a/Sources/NIO/EventLoop.swift b/Sources/NIO/EventLoop.swift
index d18a33dd..972b3b05 100644
--- a/Sources/NIO/EventLoop.swift
+++ b/Sources/NIO/EventLoop.swift
@@ -840 +840 @@ public final class MultiThreadedEventLoopGroup: EventLoopGroup {
- private enum RunState {
+ public enum RunState {
@@ -852 +852 @@ public final class MultiThreadedEventLoopGroup: EventLoopGroup {
- private var runState: RunState = .running
+ public var runState: RunState = .running
diff --git a/Sources/NIOAsyncAwaitDemo/main.swift b/Sources/NIOAsyncAwaitDemo/main.swift
index 97a9c0c3..f8b29ace 100644
--- a/Sources/NIOAsyncAwaitDemo/main.swift
+++ b/Sources/NIOAsyncAwaitDemo/main.swift
@@ -60,0 +61 @@ func main() async {
+ print("elg state: \(group.runState)") // .running
@@ -61,0 +63,7 @@ func main() async {
+ print("elg state: \(group.runState)") // .closed(nil)
+
+ /// This causes the following error:
+ /// ERROR: Cannot schedule tasks on an EventLoop that has already shut down. This will be upgraded to a forced crash in future SwiftNIO versions.
+ group.next().execute {
+ print("This will not execute.")
+ }
pr created time in 6 minutes
issue openedapple/swift-nio
Add an async implementation of EventLoopGroup.shutdownGracefully to _NIOConcurrency
EventLoopGroups sometimes need to be shutdown gracefully. This operation does not return a future (as it has no loop to execute on) but instead uses a callback. We can provide a nice async wrapper of this fairly easily by using withCheckedThrowingContinuation.
created time in 3 days
push eventapple/swift-nio
commit sha a1f405285a3bc3e4e9289bb62372f60adbd82e73
Fix tests for 32-bit platforms, tested for Android armv7 (#1877) Motivation: Get the tests passing on 32-bit platforms again. Modifications: - Change the way _UInt56.max is initialized. - Set the proper max capacity for AdaptiveRecvByteBufferAllocator and change the test to match it. - Add a cmsghdrExample for Android armv7. Result: All the same tests pass on Android armv7 as Android AArch64.
push time in 3 days
PR merged apple/swift-nio
Motivation:
Get the tests passing on 32-bit platforms again.
Modifications:
- Change the way _UInt56.max is initialized.
- Set the proper max capacity for AdaptiveRecvByteBufferAllocator and change the test to match it.
- Add a cmsghdrExample for Android armv7.
Result:
All the same tests pass on Android armv7 as Android AArch64.
Now that I have a working Android armv7 5.4 toolchain again, termux/termux-packages#6941, I noticed that the armv7 tests had regressed since February. These changes got me to parity with AArch64, ie only BootstrapTest/testClientBindWorksOnSocketsBoundToEitherIPv4OrIPv6Only fails now, will look into that later.
pr closed time in 3 days
pull request commentapple/swift-nio
Fix tests for 32-bit platforms, tested for Android armv7
@swift-nio-bot add to allowlist
comment created time in 3 days
Pull request review commentapple/swift-nio
Fix tests for 32-bit platforms, tested for Android armv7
final class AdaptiveRecvByteBufferAllocatorTest: XCTestCase { } let adaptive = AdaptiveRecvByteBufferAllocator(minimum: targetValue, initial: targetValue + 1, maximum: targetValue + 2)- XCTAssertEqual(adaptive.minimum, 1 << 31)- XCTAssertEqual(adaptive.maximum, 1 << 31)- XCTAssertEqual(adaptive.initial, 1 << 31)+ XCTAssertEqual(adaptive.minimum, 1 << 30)+ XCTAssertEqual(adaptive.maximum, 1 << 30)+ XCTAssertEqual(adaptive.initial, 1 << 30)
I had initially missed these tests that aren't run on armv7, got them after testing this pull on Android AArch64 too.
comment created time in 3 days
Pull request review commentapple/swift-nio
Fix tests for 32-bit platforms, tested for Android armv7
final class AdaptiveRecvByteBufferAllocatorTest: XCTestCase { self.adaptive = AdaptiveRecvByteBufferAllocator(minimum: 0, initial: .max / 2, maximum: .max) var mayGrow = true while mayGrow {- mayGrow = self.adaptive.record(actualReadBytes: .max)+ mayGrow = self.adaptive.record(actualReadBytes: .max / 2 )
OK, with that last change, this test change is no longer needed. Added the check you suggested and removed this halving in latest commit.
comment created time in 4 days
Pull request review commentswift-server/guides
+# Deploying to AWS on Amazon Linux 2++This guide describes how to launch an AWS instance running Amazon Linux 2 and configure it to run Swift. The approach taken here is a step by step approach through the console. This is a great way to learn, but for a more mature approach we recommend using Infrastructure as Code tools such as AWS Cloudformation, and the instances are created and managed through automated tools such as Autoscaling Groups. For one approach using those tools see this blog article: https://aws.amazon.com/blogs/opensource/continuous-delivery-with-server-side-swift-on-amazon-linux-2/++## Launch AWS Instance++Use the Service menu to select the EC2 service.++++Click on "Instances" in the "Instances" menu++++Click on "Launch Instance", either on the top of the screen, or if this is the first instance you have created in the region, in the main section of the screen.++++Choose an Amazon Machine Image (AMI). In this case the guide is assuming that we will be using Amazon Linux 2, so select that AMI type.++++Choose an instance type. Larger instances types will have more memory and CPU, but will be more expensive. To experiment is it frugal to choose a smaller instance type. In this case I have a `t2.micro` instance type selected.++++Configure instance details. If you want to access this instance directly to the internet, ensure that the subnet that you select is auto-assigns a public IP. It is assumed that the VPC has internet connectivity, which means that it needs to have a Internet Gateway (IGW) and the correct networking rules, but this is the case for the default VPC. If you wish to set this instance up in a private (non-internet accessible) VPC you will need to set up a bastion host, AWS Systems Manager Session Manager, or some other mechanism to connect to the instance.++++Add storage. The AWS EC2 launch wizard will suggest some form of storage by default. For our testing purposes this should be fine, but if you know that you need more storage, or a different storage performance requirements, then you can change the size and volume type here.++++Add tags. It is recommended you add as many tags as you need to correctly identify this server later. Especially if you have many servers, it can be difficult to remember which one was used for which purpose. At a very minimum, add a `Name` tag with something memorable.++++Configure security group. The security group is a stateful firewall that limits the traffic that is accepted by your instance. It is recommended to limit this as much as possible. In this case we are configuring it to only allow traffic on port 22 (ssh). It is recommended to restrict the source as well. To limit it to your workstation's current IP, click on the dropdown under "Source" and select "My IP".++++Launch instance. Click on "Launch", and select a key pair that you will use to connect to the instance. If you already have a keypair that you have used previously, you can reuse it here by selecting "Choose an existing key pair". Otherwise you can create a keypair now by selecting "Create a new key pair".++++Wait for instance to launch. When it is ready it will show as "running" under "Instance state", and "2/2 checks pass" under "Status Checks". Click on the instance to view the details on the bottom pane of the window, and look for the "IPv4 Public IP".++++Connect to instance. Using the keypair that you used or created in the launch step and the IP in the previous step, run ssh. Be sure to use the `-A` option with ssh so that in a future step we will be able to use the same key to connect to a second instance.++++Run the following command in the SSH terminal. Note that there may be a more up to date version of the swift toolchain. Check https://swift.org/download/#releases for the latest available toolchain url for Amazon Linux 2.++```+SwiftToolchainUrl="https://swift.org/builds/swift-5.4.1-release/amazonlinux2/swift-5.4.1-RELEASE/swift-5.4.1-RELEASE-amazonlinux2.tar.gz"+sudo yum install ruby binutils gcc git glibc-static gzip libbsd libcurl libedit libicu libsqlite libstdc++-static libuuid libxml2 tar tzdata ruby -y+cd $(mktemp -d)+wget ${SwiftToolchainUrl} -O swift.tar.gz+gunzip < swift.tar.gz | sudo tar -C / -xv --strip-components 1+```++Finally, check that Swift is correctly installed by running the Swift REPL: `swift`.++
It seems like there's a couple of different opinions :-) i.e. either reduce the moving parts by compiling on the instance, or use docker to simplify the build command. I'm happy to go in either direction, just let me know :-)
comment created time in 4 days
Pull request review commentapple/swift-nio
Fix tests for 32-bit platforms, tested for Android armv7
final class AdaptiveRecvByteBufferAllocatorTest: XCTestCase { self.adaptive = AdaptiveRecvByteBufferAllocator(minimum: 0, initial: .max / 2, maximum: .max) var mayGrow = true while mayGrow {- mayGrow = self.adaptive.record(actualReadBytes: .max)+ mayGrow = self.adaptive.record(actualReadBytes: .max / 2 )
Oh, line 105 of RecvByteBufferAllocator needs an extra check: it needs to check that self.nextReceiveBufferSize != upperBound. Otherwise this isn't growing at all.
comment created time in 4 days
Pull request review commentapple/swift-nio
Fix tests for 32-bit platforms, tested for Android armv7
final class AdaptiveRecvByteBufferAllocatorTest: XCTestCase { self.adaptive = AdaptiveRecvByteBufferAllocator(minimum: 0, initial: .max / 2, maximum: .max) var mayGrow = true while mayGrow {- mayGrow = self.adaptive.record(actualReadBytes: .max)+ mayGrow = self.adaptive.record(actualReadBytes: .max / 2 )
Made that change to check if upperBoundCandidate is negative, but I still had to make this change to the test. Otherwise, the nextReceiveBufferSize correctly maxes out at 2^30 and this test loop becomes an infinite loop: I guess because it can never reach Int32.max.
comment created time in 4 days
Pull request review commentapple/swift-nio
Fix tests for 32-bit platforms, tested for Android armv7
final class AdaptiveRecvByteBufferAllocatorTest: XCTestCase { self.adaptive = AdaptiveRecvByteBufferAllocator(minimum: 0, initial: .max / 2, maximum: .max) var mayGrow = true while mayGrow {- mayGrow = self.adaptive.record(actualReadBytes: .max)+ mayGrow = self.adaptive.record(actualReadBytes: .max / 2 )
Will do.
comment created time in 4 days
Pull request review commentapple/swift-nio
Fix tests for 32-bit platforms, tested for Android armv7
final class AdaptiveRecvByteBufferAllocatorTest: XCTestCase { self.adaptive = AdaptiveRecvByteBufferAllocator(minimum: 0, initial: .max / 2, maximum: .max) var mayGrow = true while mayGrow {- mayGrow = self.adaptive.record(actualReadBytes: .max)+ mayGrow = self.adaptive.record(actualReadBytes: .max / 2 )
That precondition shouldn't trip. Instead, the line underneath should be rewritten to be upperBound <= 0 ? instead. That will generate the correct logic, which is that we'll clamp at the maximum size.
comment created time in 4 days
Pull request review commentapple/swift-nio
Fix tests for 32-bit platforms, tested for Android armv7
final class AdaptiveRecvByteBufferAllocatorTest: XCTestCase { self.adaptive = AdaptiveRecvByteBufferAllocator(minimum: 0, initial: .max / 2, maximum: .max) var mayGrow = true while mayGrow {- mayGrow = self.adaptive.record(actualReadBytes: .max)+ mayGrow = self.adaptive.record(actualReadBytes: .max / 2 )
With this set to Int32.max, this line keeps doubling nextReceiveBufferSize until it overflows on 32-bit armv7, then this precondition trips because it thinksnextReceiveBufferSize is negative and therefore less than minimum.
This test change is just working around that overflow, should probably fix that to not overflow on 32-bit platforms instead.
comment created time in 4 days
Pull request review commentapple/swift-nio
Fix tests for 32-bit platforms, tested for Android armv7
public struct AdaptiveRecvByteBufferAllocator: RecvByteBufferAllocator { private var nextReceiveBufferSize: Int private var decreaseNow: Bool - private static let maximumAllocationSize = 1 << 31+ private static let maximumAllocationSize = 1 << 30
Scratch that, got it
comment created time in 4 days