-
Notifications
You must be signed in to change notification settings - Fork 93
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 TAsyncCompactProtocol and TAsyncFramedTransport #103
Conversation
See original Java source: https://github.com/apache/thrift/blob/master/lib/java/src/org/apache/thrift/protocol/TCompactProtocol.java#L314 Signed-off-by: aiudirog <[email protected]>
Codecov Report
@@ Coverage Diff @@
## master #103 +/- ##
==========================================
- Coverage 80.91% 80.17% -0.74%
==========================================
Files 35 39 +4
Lines 3536 3803 +267
==========================================
+ Hits 2861 3049 +188
- Misses 675 754 +79
Continue to review full report at Codecov.
|
Signed-off-by: aiudirog <[email protected]>
Thank you, this is awesome, I am reviewing it. |
self._last_fid = 0 | ||
|
||
@asyncio.coroutine | ||
def read_struct_end(self): |
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.
Seems like there are some methods do not need to add asyncio.coroutine
decorator.
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 decorated all the methods starting with read to make it easier to convert by assuming all reads were coroutines. I can change it if you like as there is a slight performance cost.
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.
Yes, if the method does not depend on I/O, it is better to remove the coroutine decorator.
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 removed all the ones I could. TAsyncClient assumes read_message_end()
is a coroutine so I left that one with the decorator.
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.
It may be worth it to go through all the different protocol classes and mark any helper methods as private so it's easier to determine which need to be async regardless of content based upon the public interface.
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.
Yes, maybe we should promise an interface to describe which methods of a protocol should be coroutines.
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 can take care of that in a dedicated PR for standardizing interfaces.
I think the refactored test cases are pretty well, thank you. |
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.
LGTM except for a small doubt as before
Signed-off-by: aiudirog <[email protected]>
Signed-off-by: aiudirog <[email protected]>
Signed-off-by: aiudirog <[email protected]>
While running the tests again, I noticed some warnings that showed the clients and servers weren't being cleaned up properly. I updated the test cases to ensure all clients are closed and I fixed a bug in |
Signed-off-by: aiudirog <[email protected]>
For consistency with the standard implementation, I've added the async versions of the compact protocol and framed transport.
I had to refactor the aio test cases because they were getting unruly. I chose to have a base test case which has all of the generic tests and then a subclass for each combination of protocol, transport, and SSL (the SSL is added as a mixin). If you don't like this design I can find a different way.
I also found a very small bug in the compact protocol where booleans with field id 0 weren't being written correctly. As you can see in the code below, the Java implementation checks to see if the bool fid is not null and if so calls their write field header (
writeFieldBeginInternal()
) where it then checks if it can compact with previous field. The Python code checks if the bool fid is falsey as well as some of the internal conditions for compacting the fields which prevents it from calling_write_field_header()
when it should.Python Source
Java Source
If the original intention was to only call
_write_field_header()
if the compaction was going to happen, this should make it work (but I think the Java implementation is more efficient as it doesn't compute the delta twice):If you leave off the bug fix commit, you should see that my test cases fail when the protocol needs to return a boolean.