-
Notifications
You must be signed in to change notification settings - Fork 567
Wakeup the waiter with exception if handshake fails #308
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
Conversation
Thanks a lot for the PR! I'll try to add a test. |
Awesome, Andrew, thank you. |
@fantix Do you want to review Andrew's CPython PR python/cpython#17975? |
@1st1 oh sure! I can look into that this weekend |
@@ -522,6 +522,7 @@ cdef class SSLProtocol: | |||
else: | |||
msg = 'SSL handshake failed' | |||
self._fatal_error(exc, msg) |
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.
@asvetlov Hi Andrew! I revisited this one today and tried to write a test - looks like in _fatal_error
:
It will call connection_lost()
, which will eventually call _wakeup_waiter()
:
I tried to send EOF during handshake and couldn't reproduce the hanging situation - I've also tried to remove this _wakeup_waiter()
call here in python/cpython#17975 and all asyncio-related tests passed. I'm worried that I might have missed something here, could you please shed some light?
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.
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.
@1st1 I think we can merge this PR without further tests, because:
- I don't think this is a bug, because we are always closing the underlying transport, that will trigger
SSLProtocol.connection_lost
and wakeup the waiter. - And the only case when this would hang is that the underlying transport didn't schedule a
connection_lost()
call on close. But in uvloop we hard-coded the transport to be one ofTCPTransport
,UnixTransport
orSSLTransport
, and the user would have to use Cython to create a buggy transport subclass to reproduce this issue. (I tried in CPython as a unit test but it seemed not quite possible) - I think making an additional wakeup is harmless, and it may save some time by triggering the waiter early. Therefore, I think we could merge this.
@fantix You can go ahead and merge this yourself. |
During the work on python/cpython#17975 I've found a minor bug in uvloop: when SSL handshake fails with an exception the waiter is not waked up; it leads to hanging.
I have no idea how to write a test for it; in asyncio we had mocked test already for
eof_received()
during SSL handshaking. As I see EOF is the only scenario that can hang; there is a very low chance that a peer will callshutdown(sock, SHUT_WR)
on own side without immediateclose(sock)
at least.Anyway, please merge if you have no objections.