dnrops
/
swift-nio
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
swift-nio/docker/docker-compose.2204.57.yaml

87 lines
3.6 KiB
YAML
Raw Normal View History

ci update (#2066) motivation: 5.6 is out changes: * use release version of 5.6 * add docker setup for 5.7 (using nightly for now)
2022-03-17 12:28:58 +08:00
version: "3"
services:
runtime-setup:
Raise minimum supported Swift version from 5.4 to 5.5 (#2267) Motivation: SwiftNIO periodically drops support for older Swift versions. Now that 5.7 has been released, 5.4 will be dropped. Modifications: - Remove 5.4 specific Package.swift and docker-compose - Update the 5.7 docker-compose to use the released 5.7 and move from focal (2004) to jammy (2204) - Remove unused swiftformat from Dockerfile - Update tools version in syscall wrapper tests to 5.5 - Update docs Results: Minimum Swift version is 5.5
2022-09-29 18:47:44 +08:00
image: swift-nio:22.04-5.7
ci update (#2066) motivation: 5.6 is out changes: * use release version of 5.6 * add docker setup for 5.7 (using nightly for now)
2022-03-17 12:28:58 +08:00
build:
args:
Update allocation limits (#2272) Motivation: a16e2f54a25b2af217044e5168997009a505930f allocates more in some cases because of an additional channel handler. Modifications: - Update alloc limits Result: CI passes.
2022-09-29 17:10:16 +08:00
ubuntu_version: "jammy"
swift_version: "5.7"
ci update (#2066) motivation: 5.6 is out changes: * use release version of 5.6 * add docker setup for 5.7 (using nightly for now)
2022-03-17 12:28:58 +08:00
unit-tests:
Raise minimum supported Swift version from 5.4 to 5.5 (#2267) Motivation: SwiftNIO periodically drops support for older Swift versions. Now that 5.7 has been released, 5.4 will be dropped. Modifications: - Remove 5.4 specific Package.swift and docker-compose - Update the 5.7 docker-compose to use the released 5.7 and move from focal (2004) to jammy (2204) - Remove unused swiftformat from Dockerfile - Update tools version in syscall wrapper tests to 5.5 - Update docs Results: Minimum Swift version is 5.5
2022-09-29 18:47:44 +08:00
image: swift-nio:22.04-5.7
ci update (#2066) motivation: 5.6 is out changes: * use release version of 5.6 * add docker setup for 5.7 (using nightly for now)
2022-03-17 12:28:58 +08:00
integration-tests:
Raise minimum supported Swift version from 5.4 to 5.5 (#2267) Motivation: SwiftNIO periodically drops support for older Swift versions. Now that 5.7 has been released, 5.4 will be dropped. Modifications: - Remove 5.4 specific Package.swift and docker-compose - Update the 5.7 docker-compose to use the released 5.7 and move from focal (2004) to jammy (2204) - Remove unused swiftformat from Dockerfile - Update tools version in syscall wrapper tests to 5.5 - Update docs Results: Minimum Swift version is 5.5
2022-09-29 18:47:44 +08:00
image: swift-nio:22.04-5.7
ci update (#2066) motivation: 5.6 is out changes: * use release version of 5.6 * add docker setup for 5.7 (using nightly for now)
2022-03-17 12:28:58 +08:00
Clean up and regression check the docs. (#2400) Motivation: Up until recently, it has not been possible to regression check our documentation. However, in recent releases of the DocC plugin it has become possible to make warnings into errors, making it possible for us to CI our docs. This patch adds support for doing that, and also cleans up our documentation so that it successfully passes the check. Along the way I accidentally wrote an `index.md` for `NIOCore` so I figure we may as well keep it. Modifications: - Structure the documentation for NIOCore - Fix up DocC issues - Add `check-docs.sh` script to check the docs cleanly build - Wire things up to our docker-compose scripts. Result: We can CI our docs. Co-authored-by: George Barnett <gbarnett@apple.com>
2023-04-11 16:05:22 +08:00
documentation-check:
image: swift-nio:22.04-5.7
ci update (#2066) motivation: 5.6 is out changes: * use release version of 5.6 * add docker setup for 5.7 (using nightly for now)
2022-03-17 12:28:58 +08:00
test:
Raise minimum supported Swift version from 5.4 to 5.5 (#2267) Motivation: SwiftNIO periodically drops support for older Swift versions. Now that 5.7 has been released, 5.4 will be dropped. Modifications: - Remove 5.4 specific Package.swift and docker-compose - Update the 5.7 docker-compose to use the released 5.7 and move from focal (2004) to jammy (2204) - Remove unused swiftformat from Dockerfile - Update tools version in syscall wrapper tests to 5.5 - Update docs Results: Minimum Swift version is 5.5
2022-09-29 18:47:44 +08:00
image: swift-nio:22.04-5.7
ci update (#2066) motivation: 5.6 is out changes: * use release version of 5.6 * add docker setup for 5.7 (using nightly for now)
2022-03-17 12:28:58 +08:00
environment:
Tail allocate mutex and a generic value using ManagedBuffer (#2349) Motivation: Currently, NIOLock and NIOLockedValueBox incur unnecessary allocation and indirection costs. Modifications: Create namespace LockOperations for organization Create LockStorage<Value>, a subclass of ManagedBuffer<LockPrimitive, Value> Store the mutex as the header and the generic value as the first and only element Update NIOLock and NIOLockedValueBox to use LockStorage Result: Optimal lock and value memory layout Fewer allocations and less indirection Code generation is excellent
2023-01-18 00:11:10 +08:00
- MAX_ALLOCS_ALLOWED_10000000_asyncsequenceproducer=22
Measure allocations applying WS mask (#2333) Motivation: We're missing some alloc tests on the WS mask. Modifications: - Add extra alloc tests for the WS mask Result: We'll have more tests
2022-12-14 02:05:27 +08:00
- MAX_ALLOCS_ALLOWED_1000000_asyncwriter=1000050
`Embedded`: `getOption(ChannelOptions.allowRemoteHalfClosure)` should not `fatalError` (#2429) * Embedded: getOption(.allowRemoteHalfClosure) -> OK Motivation: In `swift-nio-ssl`, I am currently working on allowing half-closures which relies on querying the underlying channel if `ChannelOptions.Types.AllowRemoteHalfClosureOption` is enabled. As a lot of `swift-nio-ssl`'s tests rely on `EmbeddedChannel` and it did not support this option, a lot of the tests failed. Modifications: * add a `public var allowRemoteHalfClosure` to `EmbeddedChannel` * enable setting/getting `ChannelOptions.Types.AllowRemoteHalfClosureOption` in `EmbeddedChannel` (only modifies the `allowRemoteHalfClosure` variable * add test for new behaviour * AsyncTestingChannel: getOption(.allowRemoteHalfClosure) -> OK Motivation: `AsyncTestingChannel` interface should be in step with `EmbeddedChannel` interface. Therefore also add support for the `AllowRemoteHalfClosureOption` Modifications: * add a `public var allowRemoteHalfClosure` to `AsyncTestingChannel` * enable setting/getting `ChannelOptions.Types.AllowRemoteHalfClosureOption` in `AsyncTestingChannel` (only modifies the `allowRemoteHalfClosure` variable * add tests for new behaviour * Synchronize access to allowRemoteHalfClosure Modifications: * add `ManagedAtomic` property `_allowRemoteHalfClosure` to `EmbeddedChannelCore` * make sure that access to `allowRemoteHalfClosure` from `AsyncTestingChannel` and `EmbeddedChannel` is synchronized by accessing underlying atomic value in `channelcore` * Update allocation limits
2023-05-20 00:47:47 +08:00
- MAX_ALLOCS_ALLOWED_1000_addHandlers=45050
- MAX_ALLOCS_ALLOWED_1000_addHandlers_sync=39050
Tail allocate mutex and a generic value using ManagedBuffer (#2349) Motivation: Currently, NIOLock and NIOLockedValueBox incur unnecessary allocation and indirection costs. Modifications: Create namespace LockOperations for organization Create LockStorage<Value>, a subclass of ManagedBuffer<LockPrimitive, Value> Store the mutex as the header and the generic value as the first and only element Update NIOLock and NIOLockedValueBox to use LockStorage Result: Optimal lock and value memory layout Fewer allocations and less indirection Code generation is excellent
2023-01-18 00:11:10 +08:00
- MAX_ALLOCS_ALLOWED_1000_addRemoveHandlers_handlercontext=8050
- MAX_ALLOCS_ALLOWED_1000_addRemoveHandlers_handlername=8050
- MAX_ALLOCS_ALLOWED_1000_addRemoveHandlers_handlertype=8050
- MAX_ALLOCS_ALLOWED_1000_autoReadGetAndSet=18050
ci update (#2066) motivation: 5.6 is out changes: * use release version of 5.6 * add docker setup for 5.7 (using nightly for now)
2022-03-17 12:28:58 +08:00
- MAX_ALLOCS_ALLOWED_1000_autoReadGetAndSet_sync=0
- MAX_ALLOCS_ALLOWED_1000_copying_bytebufferview_to_array=1050
- MAX_ALLOCS_ALLOWED_1000_copying_circularbuffer_to_array=1050
Tail allocate mutex and a generic value using ManagedBuffer (#2349) Motivation: Currently, NIOLock and NIOLockedValueBox incur unnecessary allocation and indirection costs. Modifications: Create namespace LockOperations for organization Create LockStorage<Value>, a subclass of ManagedBuffer<LockPrimitive, Value> Store the mutex as the header and the generic value as the first and only element Update NIOLock and NIOLockedValueBox to use LockStorage Result: Optimal lock and value memory layout Fewer allocations and less indirection Code generation is excellent
2023-01-18 00:11:10 +08:00
- MAX_ALLOCS_ALLOWED_1000_getHandlers=8050
`Embedded`: `getOption(ChannelOptions.allowRemoteHalfClosure)` should not `fatalError` (#2429) * Embedded: getOption(.allowRemoteHalfClosure) -> OK Motivation: In `swift-nio-ssl`, I am currently working on allowing half-closures which relies on querying the underlying channel if `ChannelOptions.Types.AllowRemoteHalfClosureOption` is enabled. As a lot of `swift-nio-ssl`'s tests rely on `EmbeddedChannel` and it did not support this option, a lot of the tests failed. Modifications: * add a `public var allowRemoteHalfClosure` to `EmbeddedChannel` * enable setting/getting `ChannelOptions.Types.AllowRemoteHalfClosureOption` in `EmbeddedChannel` (only modifies the `allowRemoteHalfClosure` variable * add test for new behaviour * AsyncTestingChannel: getOption(.allowRemoteHalfClosure) -> OK Motivation: `AsyncTestingChannel` interface should be in step with `EmbeddedChannel` interface. Therefore also add support for the `AllowRemoteHalfClosureOption` Modifications: * add a `public var allowRemoteHalfClosure` to `AsyncTestingChannel` * enable setting/getting `ChannelOptions.Types.AllowRemoteHalfClosureOption` in `AsyncTestingChannel` (only modifies the `allowRemoteHalfClosure` variable * add tests for new behaviour * Synchronize access to allowRemoteHalfClosure Modifications: * add `ManagedAtomic` property `_allowRemoteHalfClosure` to `EmbeddedChannelCore` * make sure that access to `allowRemoteHalfClosure` from `AsyncTestingChannel` and `EmbeddedChannel` is synchronized by accessing underlying atomic value in `channelcore` * Update allocation limits
2023-05-20 00:47:47 +08:00
- MAX_ALLOCS_ALLOWED_1000_getHandlers_sync=36
Add a pooled recv buffer allocator (#2362) Motivation: Channels can read `ChannelOptions.maxMessagesPerRead` times from a socket in each read cycle. They typically re-use the same buffer for each read and rely on it CoWing if necessary. If we read more than once in a cycle then we may CoW the buffer. Instead of reusing one buffer we can reuse a pool of buffers limited by `maxMessagesPerRead` and cycle through each, reducing the chance of CoWing the buffers. Modifications: - Extend `RecvByteBufferAllocator` to provide the size of the next buffer with a default implementation returning `nil`. - Add an recv buffer pool which lazily grows up to a fixed size and attempts to reuse buffers where possible if doing so avoids CoWing. Results: Fewer allocations
2023-02-21 01:00:19 +08:00
- MAX_ALLOCS_ALLOWED_1000_reqs_1_conn=26400
`Embedded`: `getOption(ChannelOptions.allowRemoteHalfClosure)` should not `fatalError` (#2429) * Embedded: getOption(.allowRemoteHalfClosure) -> OK Motivation: In `swift-nio-ssl`, I am currently working on allowing half-closures which relies on querying the underlying channel if `ChannelOptions.Types.AllowRemoteHalfClosureOption` is enabled. As a lot of `swift-nio-ssl`'s tests rely on `EmbeddedChannel` and it did not support this option, a lot of the tests failed. Modifications: * add a `public var allowRemoteHalfClosure` to `EmbeddedChannel` * enable setting/getting `ChannelOptions.Types.AllowRemoteHalfClosureOption` in `EmbeddedChannel` (only modifies the `allowRemoteHalfClosure` variable * add test for new behaviour * AsyncTestingChannel: getOption(.allowRemoteHalfClosure) -> OK Motivation: `AsyncTestingChannel` interface should be in step with `EmbeddedChannel` interface. Therefore also add support for the `AllowRemoteHalfClosureOption` Modifications: * add a `public var allowRemoteHalfClosure` to `AsyncTestingChannel` * enable setting/getting `ChannelOptions.Types.AllowRemoteHalfClosureOption` in `AsyncTestingChannel` (only modifies the `allowRemoteHalfClosure` variable * add tests for new behaviour * Synchronize access to allowRemoteHalfClosure Modifications: * add `ManagedAtomic` property `_allowRemoteHalfClosure` to `EmbeddedChannelCore` * make sure that access to `allowRemoteHalfClosure` from `AsyncTestingChannel` and `EmbeddedChannel` is synchronized by accessing underlying atomic value in `channelcore` * Update allocation limits
2023-05-20 00:47:47 +08:00
- MAX_ALLOCS_ALLOWED_1000_rst_connections=147050
ci update (#2066) motivation: 5.6 is out changes: * use release version of 5.6 * add docker setup for 5.7 (using nightly for now)
2022-03-17 12:28:58 +08:00
- MAX_ALLOCS_ALLOWED_1000_tcpbootstraps=4050
Add a pooled recv buffer allocator (#2362) Motivation: Channels can read `ChannelOptions.maxMessagesPerRead` times from a socket in each read cycle. They typically re-use the same buffer for each read and rely on it CoWing if necessary. If we read more than once in a cycle then we may CoW the buffer. Instead of reusing one buffer we can reuse a pool of buffers limited by `maxMessagesPerRead` and cycle through each, reducing the chance of CoWing the buffers. Modifications: - Extend `RecvByteBufferAllocator` to provide the size of the next buffer with a default implementation returning `nil`. - Add an recv buffer pool which lazily grows up to a fixed size and attempts to reuse buffers where possible if doing so avoids CoWing. Results: Fewer allocations
2023-02-21 01:00:19 +08:00
- MAX_ALLOCS_ALLOWED_1000_tcpconnections=154050
- MAX_ALLOCS_ALLOWED_1000_udp_reqs=6050
ci update (#2066) motivation: 5.6 is out changes: * use release version of 5.6 * add docker setup for 5.7 (using nightly for now)
2022-03-17 12:28:58 +08:00
- MAX_ALLOCS_ALLOWED_1000_udpbootstraps=2050
Add a pooled recv buffer allocator (#2362) Motivation: Channels can read `ChannelOptions.maxMessagesPerRead` times from a socket in each read cycle. They typically re-use the same buffer for each read and rely on it CoWing if necessary. If we read more than once in a cycle then we may CoW the buffer. Instead of reusing one buffer we can reuse a pool of buffers limited by `maxMessagesPerRead` and cycle through each, reducing the chance of CoWing the buffers. Modifications: - Extend `RecvByteBufferAllocator` to provide the size of the next buffer with a default implementation returning `nil`. - Add an recv buffer pool which lazily grows up to a fixed size and attempts to reuse buffers where possible if doing so avoids CoWing. Results: Fewer allocations
2023-02-21 01:00:19 +08:00
- MAX_ALLOCS_ALLOWED_1000_udpconnections=77050
`Embedded`: `getOption(ChannelOptions.allowRemoteHalfClosure)` should not `fatalError` (#2429) * Embedded: getOption(.allowRemoteHalfClosure) -> OK Motivation: In `swift-nio-ssl`, I am currently working on allowing half-closures which relies on querying the underlying channel if `ChannelOptions.Types.AllowRemoteHalfClosureOption` is enabled. As a lot of `swift-nio-ssl`'s tests rely on `EmbeddedChannel` and it did not support this option, a lot of the tests failed. Modifications: * add a `public var allowRemoteHalfClosure` to `EmbeddedChannel` * enable setting/getting `ChannelOptions.Types.AllowRemoteHalfClosureOption` in `EmbeddedChannel` (only modifies the `allowRemoteHalfClosure` variable * add test for new behaviour * AsyncTestingChannel: getOption(.allowRemoteHalfClosure) -> OK Motivation: `AsyncTestingChannel` interface should be in step with `EmbeddedChannel` interface. Therefore also add support for the `AllowRemoteHalfClosureOption` Modifications: * add a `public var allowRemoteHalfClosure` to `AsyncTestingChannel` * enable setting/getting `ChannelOptions.Types.AllowRemoteHalfClosureOption` in `AsyncTestingChannel` (only modifies the `allowRemoteHalfClosure` variable * add tests for new behaviour * Synchronize access to allowRemoteHalfClosure Modifications: * add `ManagedAtomic` property `_allowRemoteHalfClosure` to `EmbeddedChannelCore` * make sure that access to `allowRemoteHalfClosure` from `AsyncTestingChannel` and `EmbeddedChannel` is synchronized by accessing underlying atomic value in `channelcore` * Update allocation limits
2023-05-20 00:47:47 +08:00
- MAX_ALLOCS_ALLOWED_1_reqs_1000_conn=400050
ci update (#2066) motivation: 5.6 is out changes: * use release version of 5.6 * add docker setup for 5.7 (using nightly for now)
2022-03-17 12:28:58 +08:00
- MAX_ALLOCS_ALLOWED_bytebuffer_lots_of_rw=2050
- MAX_ALLOCS_ALLOWED_creating_10000_headers=0
- MAX_ALLOCS_ALLOWED_decode_1000_ws_frames=2050
- MAX_ALLOCS_ALLOWED_encode_1000_ws_frames_holding_buffer=3
Measure allocations applying WS mask (#2333) Motivation: We're missing some alloc tests on the WS mask. Modifications: - Add extra alloc tests for the WS mask Result: We'll have more tests
2022-12-14 02:05:27 +08:00
- MAX_ALLOCS_ALLOWED_encode_1000_ws_frames_holding_buffer_with_mask=2050
ci update (#2066) motivation: 5.6 is out changes: * use release version of 5.6 * add docker setup for 5.7 (using nightly for now)
2022-03-17 12:28:58 +08:00
- MAX_ALLOCS_ALLOWED_encode_1000_ws_frames_holding_buffer_with_space=3
Measure allocations applying WS mask (#2333) Motivation: We're missing some alloc tests on the WS mask. Modifications: - Add extra alloc tests for the WS mask Result: We'll have more tests
2022-12-14 02:05:27 +08:00
- MAX_ALLOCS_ALLOWED_encode_1000_ws_frames_holding_buffer_with_space_with_mask=2050
ci update (#2066) motivation: 5.6 is out changes: * use release version of 5.6 * add docker setup for 5.7 (using nightly for now)
2022-03-17 12:28:58 +08:00
- MAX_ALLOCS_ALLOWED_encode_1000_ws_frames_new_buffer=3050
Measure allocations applying WS mask (#2333) Motivation: We're missing some alloc tests on the WS mask. Modifications: - Add extra alloc tests for the WS mask Result: We'll have more tests
2022-12-14 02:05:27 +08:00
- MAX_ALLOCS_ALLOWED_encode_1000_ws_frames_new_buffer_with_mask=5050
ci update (#2066) motivation: 5.6 is out changes: * use release version of 5.6 * add docker setup for 5.7 (using nightly for now)
2022-03-17 12:28:58 +08:00
- MAX_ALLOCS_ALLOWED_encode_1000_ws_frames_new_buffer_with_space=3050
Measure allocations applying WS mask (#2333) Motivation: We're missing some alloc tests on the WS mask. Modifications: - Add extra alloc tests for the WS mask Result: We'll have more tests
2022-12-14 02:05:27 +08:00
- MAX_ALLOCS_ALLOWED_encode_1000_ws_frames_new_buffer_with_space_with_mask=5050
ci update (#2066) motivation: 5.6 is out changes: * use release version of 5.6 * add docker setup for 5.7 (using nightly for now)
2022-03-17 12:28:58 +08:00
- MAX_ALLOCS_ALLOWED_execute_hop_10000_tasks=0
- MAX_ALLOCS_ALLOWED_future_erase_result=4050
Tail allocate mutex and a generic value using ManagedBuffer (#2349) Motivation: Currently, NIOLock and NIOLockedValueBox incur unnecessary allocation and indirection costs. Modifications: Create namespace LockOperations for organization Create LockStorage<Value>, a subclass of ManagedBuffer<LockPrimitive, Value> Store the mutex as the header and the generic value as the first and only element Update NIOLock and NIOLockedValueBox to use LockStorage Result: Optimal lock and value memory layout Fewer allocations and less indirection Code generation is excellent
2023-01-18 00:11:10 +08:00
- MAX_ALLOCS_ALLOWED_future_lots_of_callbacks=53050
ci update (#2066) motivation: 5.6 is out changes: * use release version of 5.6 * add docker setup for 5.7 (using nightly for now)
2022-03-17 12:28:58 +08:00
- MAX_ALLOCS_ALLOWED_get_100000_headers_canonical_form=700050
- MAX_ALLOCS_ALLOWED_get_100000_headers_canonical_form_trimming_whitespace=700050
- MAX_ALLOCS_ALLOWED_get_100000_headers_canonical_form_trimming_whitespace_from_long_string=700050
- MAX_ALLOCS_ALLOWED_get_100000_headers_canonical_form_trimming_whitespace_from_short_string=700050
- MAX_ALLOCS_ALLOWED_modifying_1000_circular_buffer_elements=0
Update alloc limits for nightly. (#2071) We regressed allocs in nightly, probably for a Swift bug. Fixing it is tracked in #2070, for now we're going to raise the limits so CI isn't moaning all the time.
2022-03-24 01:05:11 +08:00
- MAX_ALLOCS_ALLOWED_modifying_byte_buffer_view=6050
Add a pooled recv buffer allocator (#2362) Motivation: Channels can read `ChannelOptions.maxMessagesPerRead` times from a socket in each read cycle. They typically re-use the same buffer for each read and rely on it CoWing if necessary. If we read more than once in a cycle then we may CoW the buffer. Instead of reusing one buffer we can reuse a pool of buffers limited by `maxMessagesPerRead` and cycle through each, reducing the chance of CoWing the buffers. Modifications: - Extend `RecvByteBufferAllocator` to provide the size of the next buffer with a default implementation returning `nil`. - Add an recv buffer pool which lazily grows up to a fixed size and attempts to reuse buffers where possible if doing so avoids CoWing. Results: Fewer allocations
2023-02-21 01:00:19 +08:00
- MAX_ALLOCS_ALLOWED_ping_pong_1000_reqs_1_conn=341
ci update (#2066) motivation: 5.6 is out changes: * use release version of 5.6 * add docker setup for 5.7 (using nightly for now)
2022-03-17 12:28:58 +08:00
- MAX_ALLOCS_ALLOWED_read_10000_chunks_from_file=140050
Reduce the alloc limits for main (#2118) The nightly builds have improved, so the alloc limits can drop slightly
2022-05-17 00:56:45 +08:00
- MAX_ALLOCS_ALLOWED_schedule_10000_tasks=50100
- MAX_ALLOCS_ALLOWED_schedule_and_run_10000_tasks=50050
`Embedded`: `getOption(ChannelOptions.allowRemoteHalfClosure)` should not `fatalError` (#2429) * Embedded: getOption(.allowRemoteHalfClosure) -> OK Motivation: In `swift-nio-ssl`, I am currently working on allowing half-closures which relies on querying the underlying channel if `ChannelOptions.Types.AllowRemoteHalfClosureOption` is enabled. As a lot of `swift-nio-ssl`'s tests rely on `EmbeddedChannel` and it did not support this option, a lot of the tests failed. Modifications: * add a `public var allowRemoteHalfClosure` to `EmbeddedChannel` * enable setting/getting `ChannelOptions.Types.AllowRemoteHalfClosureOption` in `EmbeddedChannel` (only modifies the `allowRemoteHalfClosure` variable * add test for new behaviour * AsyncTestingChannel: getOption(.allowRemoteHalfClosure) -> OK Motivation: `AsyncTestingChannel` interface should be in step with `EmbeddedChannel` interface. Therefore also add support for the `AllowRemoteHalfClosureOption` Modifications: * add a `public var allowRemoteHalfClosure` to `AsyncTestingChannel` * enable setting/getting `ChannelOptions.Types.AllowRemoteHalfClosureOption` in `AsyncTestingChannel` (only modifies the `allowRemoteHalfClosure` variable * add tests for new behaviour * Synchronize access to allowRemoteHalfClosure Modifications: * add `ManagedAtomic` property `_allowRemoteHalfClosure` to `EmbeddedChannelCore` * make sure that access to `allowRemoteHalfClosure` from `AsyncTestingChannel` and `EmbeddedChannel` is synchronized by accessing underlying atomic value in `channelcore` * Update allocation limits
2023-05-20 00:47:47 +08:00
- MAX_ALLOCS_ALLOWED_scheduling_10000_executions=85
Add a pooled recv buffer allocator (#2362) Motivation: Channels can read `ChannelOptions.maxMessagesPerRead` times from a socket in each read cycle. They typically re-use the same buffer for each read and rely on it CoWing if necessary. If we read more than once in a cycle then we may CoW the buffer. Instead of reusing one buffer we can reuse a pool of buffers limited by `maxMessagesPerRead` and cycle through each, reducing the chance of CoWing the buffers. Modifications: - Extend `RecvByteBufferAllocator` to provide the size of the next buffer with a default implementation returning `nil`. - Add an recv buffer pool which lazily grows up to a fixed size and attempts to reuse buffers where possible if doing so avoids CoWing. Results: Fewer allocations
2023-02-21 01:00:19 +08:00
- MAX_ALLOCS_ALLOWED_udp_1000_reqs_1_conn=6200
- MAX_ALLOCS_ALLOWED_udp_1_reqs_1000_conn=167050
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
- FORCE_TEST_DISCOVERY=--enable-test-discovery
- WARN_AS_ERROR_ARG=-Xswiftc -warnings-as-errors
ci update (#2066) motivation: 5.6 is out changes: * use release version of 5.6 * add docker setup for 5.7 (using nightly for now)
2022-03-17 12:28:58 +08:00
# - SANITIZER_ARG=--sanitize=thread # TSan broken still
performance-test:
Raise minimum supported Swift version from 5.4 to 5.5 (#2267) Motivation: SwiftNIO periodically drops support for older Swift versions. Now that 5.7 has been released, 5.4 will be dropped. Modifications: - Remove 5.4 specific Package.swift and docker-compose - Update the 5.7 docker-compose to use the released 5.7 and move from focal (2004) to jammy (2204) - Remove unused swiftformat from Dockerfile - Update tools version in syscall wrapper tests to 5.5 - Update docs Results: Minimum Swift version is 5.5
2022-09-29 18:47:44 +08:00
image: swift-nio:22.04-5.7
ci update (#2066) motivation: 5.6 is out changes: * use release version of 5.6 * add docker setup for 5.7 (using nightly for now)
2022-03-17 12:28:58 +08:00
shell:
Raise minimum supported Swift version from 5.4 to 5.5 (#2267) Motivation: SwiftNIO periodically drops support for older Swift versions. Now that 5.7 has been released, 5.4 will be dropped. Modifications: - Remove 5.4 specific Package.swift and docker-compose - Update the 5.7 docker-compose to use the released 5.7 and move from focal (2004) to jammy (2204) - Remove unused swiftformat from Dockerfile - Update tools version in syscall wrapper tests to 5.5 - Update docs Results: Minimum Swift version is 5.5
2022-09-29 18:47:44 +08:00
image: swift-nio:22.04-5.7
ci update (#2066) motivation: 5.6 is out changes: * use release version of 5.6 * add docker setup for 5.7 (using nightly for now)
2022-03-17 12:28:58 +08:00
echo:
Raise minimum supported Swift version from 5.4 to 5.5 (#2267) Motivation: SwiftNIO periodically drops support for older Swift versions. Now that 5.7 has been released, 5.4 will be dropped. Modifications: - Remove 5.4 specific Package.swift and docker-compose - Update the 5.7 docker-compose to use the released 5.7 and move from focal (2004) to jammy (2204) - Remove unused swiftformat from Dockerfile - Update tools version in syscall wrapper tests to 5.5 - Update docs Results: Minimum Swift version is 5.5
2022-09-29 18:47:44 +08:00
image: swift-nio:22.04-5.7
ci update (#2066) motivation: 5.6 is out changes: * use release version of 5.6 * add docker setup for 5.7 (using nightly for now)
2022-03-17 12:28:58 +08:00
http:
Raise minimum supported Swift version from 5.4 to 5.5 (#2267) Motivation: SwiftNIO periodically drops support for older Swift versions. Now that 5.7 has been released, 5.4 will be dropped. Modifications: - Remove 5.4 specific Package.swift and docker-compose - Update the 5.7 docker-compose to use the released 5.7 and move from focal (2004) to jammy (2204) - Remove unused swiftformat from Dockerfile - Update tools version in syscall wrapper tests to 5.5 - Update docs Results: Minimum Swift version is 5.5
2022-09-29 18:47:44 +08:00
image: swift-nio:22.04-5.7