-
-
Notifications
You must be signed in to change notification settings - Fork 178
Raise RuntimeError when transport's FD is used with add_reader etc #420
Conversation
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.
Looks good
After failed tests fixing, of course. |
Thank you Andrew! @gvanrossum would be cool if you can take a quick look over this PR, I want to merge it before beta2. |
I'm confused. Where is |
@gvanrossum Transports register when they are being constructed: https://github.com/python/asyncio/pull/420/files#diff-ddadd6cf041d620407e07c7c4f1b0149R572 |
I see. What about transports that don't inherit from _SelectorTransport? I guess those don't get this error when misused in debug mode but otherwise no harm is done right? If that's so I think this is fine for b2. |
Random thought. It would be cool to have |
@gvanrossum I think we cover all transports except
@asvetlov Let's think about that after 3.6 :) |
Agree |
Committed by hand, closing this PR now. |
This PR fixes #372.
The idea is that low-level socket APIs should refuse to work with FDs that belong to some
Transport
.This PR adds private implementations for
add_writer
,add_reader
,remove_writer
, andremove_reader
. Transports only call private implementation.Public implementations of those methods do an extra check on the FD, raising a
RuntimeError
when the FD belongs to someTransport
.loop.sock_sendall
,loop.sock_connect
,loop.sock_accept
andloop.sock_recv
only call public methods.FWIW uvloop has a lot of functional network unittests, all of them pass on asyncio with this patch.