Tags: alex-taffe/swift-nio
Tags
Avoid using deinit to fulfil the protocol negotiation promise (apple#… …2497) # Motivation Fixes apple#2494 # Modification This PR avoids using `deinit` to fulfil the protocol negotiation promise and opts to trap instead when it is being accessed before the handler is added. This allows us to use `handlerAdded` and `handlerRemoved`. # Result No more `deinit` usage that can be observed.
Add configuration for `NIOAsyncChannel` (apple#2464) # Motivation While adopting the new `NIOAsyncChannel` type we saw an exploding number of parameters passed to the various connect/bind/configure methods. All these methods had in common that we had to pass configuration for the `NIOAsyncChannel`. # Modification This PR introduces a new type `NIOAsyncChannel.Configuration` which groups all four configuration parameters into a struct. # Result We can now write more concise methods that use a single configuration object.
Fix last remaining test on Android (apple#2457) Motivation Get all tests passing on Android AArch64 Modifications - Check if localhost is set for IPv6 in BootstrapTest/testClientBindWorksOnSocketsBoundToEitherIPv4OrIPv6Only, and use ip6-localhost if not Result All tests pass natively on Android AArch64
Tolerate sending data after close(mode: .output) (apple#2421) Motivation We shouldn't crash on somewhat likely user error. Modifications Pass on writes after close(mode: .output) instead of crashing. Result User code is more robust to weird edge cases.
NIOThrowingAsyncSequenceProducer throws when cancelled (apple#2415) * NIOThrowingAsyncSequenceProducer throws when cancelled * PR review
Avoid double-closing on fcntl failures (apple#2409) Motivation: The fix provided in apple#2407 was subtly wrong. ignoreSIGPIPE, which throws the error in question, closes the FD on error _except_ on EINVAL from fcntl, where it instead does not. This inconsistent behaviour is the source of the bug. Because this behaviour is inconsistent, the fix from PR apple#2407 is also inconsistent and can in some cases double-close the socket. The actual issue is not as old as I expected: the code can be observed by reviewing the change in apple#1598, which incorrectly inserted the error transformation before the call to close. Modifications: - Revert the change from apple#2407. - Move the close in ignoreSIGPIPE to before the error check, rather than after, so we unconditionally execute it. Result: More resilient fix.
Throw `CancellationError` instead of returning `nil` during early can… …cellation. (apple#2401) ### Motivation: Follow up PR for apple#2399 We currently still return `nil` if the current `Task` is canceled before the first call to `NIOThrowingAsyncSequenceProducer.AsyncIterator.next()` but it should throw `CancellationError` too. In addition, the generic `Failure` type turns out to be a problem. Just throwing a `CancellationError` without checking that `Failure` type is `any Swift.Error` or `CancellationError` introduced a type safety violation as we throw an unrelated type. ### Modifications: - throw `CancellationError` on eager cancellation - deprecates the generic `Failure` type of `NIOThrowingAsyncSequenceProducer`. It now must always be `any Swift.Error`. For backward compatibility we will still return nil if `Failure` is not `any Swift.Error` or `CancellationError`. ### Result: `CancellationError` is now correctly thrown instead of returning `nil` on eager cancelation. Generic `Failure` type is deprecated.
PreviousNext