profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/weissi/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

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.

kylebrowning/APNSwift 396

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.

MrLotU/SwiftPrometheus 58

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?

simonjbeaumont

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.

simonjbeaumont

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?

simonjbeaumont

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?

simonjbeaumont

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?

simonjbeaumont

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?

simonjbeaumont

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?

simonjbeaumont

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?

simonjbeaumont

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?

simonjbeaumont

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?

simonjbeaumont

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?

simonjbeaumont

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?

simonjbeaumont

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?

simonjbeaumont

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?

simonjbeaumont

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?

simonjbeaumont

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?

simonjbeaumont

comment created time in 6 minutes

PR opened apple/swift-nio

Add async implementation of EventLoopGroup.shutdownGracefully to _NIOConcurrency

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.")
+        }
+19 -0

0 comment

2 changed files

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

buttaface

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.

view details

push time in 3 days

PR merged apple/swift-nio

Fix tests for 32-bit platforms, tested for Android armv7 patch-version-bump-only

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.

+26 -9

15 comments

4 changed files

buttaface

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

buttaface

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.

buttaface

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.

buttaface

comment created time in 4 days

Pull request review commentswift-server/guides

Guide for AWS

+# 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.++![Select EC2 service](../images/aws/services.png)++Click on "Instances" in the "Instances" menu++![Select Instances](../images/aws/ec2.png)++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.++![Launch instance](../images/aws/launch-0.png)++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 AMI](../images/aws/launch-1.png)++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.++![Choose Instance type](../images/aws/launch-2.png)++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.++![Choose Instance details](../images/aws/launch-3.png)++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.++![Choose Instance storage](../images/aws/launch-4.png)++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.++![Add tags](../images/aws/launch-5.png)++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".++![Configure security group](../images/aws/launch-6.png)++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".++![Launch instance](../images/aws/launch-7.png)++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".++![Wait for instance launch and view details](../images/aws/ec2-list.png)++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.++![Connect to instance](../images/aws/ssh-0.png)++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`.++![Invoke REPL](../images/aws/repl.png)

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 :-)

gibbster

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.

buttaface

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.

buttaface

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.

buttaface

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.

buttaface

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.

buttaface

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

buttaface

comment created time in 4 days