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

Releasing v2.2.0 #481

Closed
5 tasks
kazu-yamamoto opened this issue Oct 17, 2024 · 6 comments
Closed
5 tasks

Releasing v2.2.0 #481

kazu-yamamoto opened this issue Oct 17, 2024 · 6 comments

Comments

@kazu-yamamoto
Copy link
Collaborator

kazu-yamamoto commented Oct 17, 2024

Relaxing boundary on Hackage

  • crypton-connection
  • http3

Fixing and releasing

  • tls
  • warp-tls
  • http2-tls

Cc: @edsko @FinleyMcIlwaine

@kazu-yamamoto
Copy link
Collaborator Author

bye is used in connectionClose of crypton-connection which is typically used in bracket, sigh.

@kazu-yamamoto
Copy link
Collaborator Author

bye could be implemented without timeout which uses the asynchronous exception.
We need two parts:

(1) TimeManager of GHC: this is easy
(2) Non-blocking recv: this is possible with the normal blocking recv if we can check its readability. We have such a feature for Socket. But I don't know such a feature for Handle.

We need to consider dropping the support for Handle in tls.

@kazu-yamamoto
Copy link
Collaborator Author

kazu-yamamoto commented Oct 23, 2024

It appeared that timeout can be used in bracket. haskell/network#589

  • The version should be reverted into v2.1.
  • The doc of bye should be relaxed.
  • unliftio should be removed.

@edsko
Copy link
Contributor

edsko commented Oct 23, 2024

Just for my understanding, what do you mean by this?

The doc of bye should be relaxed.

@kazu-yamamoto
Copy link
Collaborator Author

I wrote that bye MUST NOT be used with bracket but now the usage is allowed as it used to be. (6eb4e53)

@edsko
Copy link
Contributor

edsko commented Oct 24, 2024

Hmm, but I think there is some harm at least in using it in a bracket pattern. If the connection is broken, resulting in an exception in the body, the call to bye will then try to initiate the TLS shutdown sequence, resulting in a different exception, obscuring the original, unless we swallow exceptions in bye (but that would then mean that if the TLS shutdown sequence itself fails, we'd not see the exception, which is potentially problematic also).

But fair enough, I don't feel terribly strongly here :) The recommended usage in the docs is okay with me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants