Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add additional NIOAsyncChannel config #406

Merged
merged 4 commits into from Jul 4, 2023
Merged

Conversation

rnro
Copy link
Contributor

@rnro rnro commented Jul 4, 2023

Motivation:

Recent additions to pipeline configuration did not expose some of the NIOAsyncChannel configuration.

Modifications:

Expose backpressureStrategy, isOutboundHalfClosureEnabled.

I think specific naming and object encapsulation for these parameters should be discussed later before SPI is removed and we review the API as a whole.

Result:

Pipelie helpers for NIOAsyncChannel expose backpressureStrategy, isOutboundHalfClosureEnabled.

Motivation:

Recent additions to pipeline configuration did not expose some of the
`NIOAsyncChannel` configuration.

Modifications:

Expose `backpressureStrategy`, `isOutboundHalfClosureEnabled`.

I think specific naming and object encapsulation for these parameters should be discussed
later before SPI is removed and we review the API as a whole.

Result:

Pipelie helpers for `NIOAsyncChannel` expose `backpressureStrategy`, `isOutboundHalfClosureEnabled`.
Comment on lines 261 to 264
backpressureStrategy: NIOAsyncSequenceProducerBackPressureStrategies.HighLowWatermark? = nil,
isOutboundHalfClosureEnabled: Bool = false,
inboundType: Inbound.Type,
outboundType: Outbound.Type,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we reorder these so {in,out}boundType come first? Required parameters should come first.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should add defaults to the types as well like this = Inbound.self. Then the order is the same as in our bootstrap

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we want to add defaults here to force people to consider what types are used. This was also mentioned in an earlier PR #403 (comment)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not really a default. If you write inboundType: Inbound.Type = Inbound.self it will allow the user to either write out the generic return type which will get inferred or pass parameters. If you don't add this default value then they always have to write out the parameters even though type inference doesn't need it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, good point. I've added these in the latest commit and put the parameters back in the order to match NIOAsyncChannel.

@rnro rnro requested review from glbrntt and FranzBusch July 4, 2023 13:47
Copy link
Contributor

@FranzBusch FranzBusch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM except one minor nit

@@ -258,10 +258,10 @@ extension NIOHTTP2Handler {
@available(macOS 10.15, iOS 13.0, watchOS 6.0, tvOS 13.0, *)
@_spi(AsyncChannel)
public func createStreamChannel<Inbound, Outbound>(
inboundType: Inbound.Type = Inbound.self,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This order seems different than the other methods

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good spot

@rnro
Copy link
Contributor Author

rnro commented Jul 4, 2023

The API breakages are safe because these changes were added since the last release.

1 similar comment
@rnro
Copy link
Contributor Author

rnro commented Jul 4, 2023

The API breakages are safe because these changes were added since the last release.

@Lukasa Lukasa merged commit 6e35856 into apple:main Jul 4, 2023
7 of 8 checks passed
@rnro rnro added the needs-no-version-bump For PRs that when merged do not need a bump in version number. label Oct 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs-no-version-bump For PRs that when merged do not need a bump in version number.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants