-
Notifications
You must be signed in to change notification settings - Fork 118
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
Introduce async callbacks #134
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
3691580
to
8c6fd07
Compare
31af102
to
71dad44
Compare
This comment was marked as outdated.
This comment was marked as outdated.
2694e68
to
e5bb7c6
Compare
I removed the biggest breaking change (the removal of |
ed4142d
to
abf3ec4
Compare
The one missing thing from the PR is tests for |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit nervous about a few things I see, and I'd like to go over this more thoroughly tomorrow or Monday.
df99127
to
2ba3db5
Compare
032898f
to
f837aeb
Compare
These lists are hardcoded and the calls have no business failing in the first place.
These two new kinds of methods immediately return a MidHandshakeSslStream instead of actually initiating a handshake. This greatly simplifies loops around MidHandshakeSslStream::WouldBlock.
This encapsulates a bit better the unsafety of task context management to invoke async code from inside boring.
To handle lifetimes better and allow returning a &mut SslRef from the client hello struct passed to the closure from SslContextBuilder::set_select_certificate_callback, we make the ClientHello struct itself own a reference to the FFI client hello struct.
We introduce tokio_boring::SslContextBuilderExt, with 2 methods: * set_async_select_certificate_callback * set_async_private_key_method
No description provided.