tree ba2ffa394398ea56c21f361d873627264a628c60
parent 9fd134f269ccadd3a77a198d0c27c0a0d7c9c723
author Yuxuan 'fishy' Wang <yuxuan.wang@reddit.com> 1591615941 -0700
committer GitHub <noreply@github.com> 1591615941 +0100
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsBcBAABCAAQBQJe3iHFCRBK7hj4Ov3rIwAAdHIIACEsVBrKeHwbKZ6wzIcJLKBs
 DSvWiqyrINPopVDr+KOLZUxHNK5z7jtatL5uh3w9Wu2U6q8RzwyoCc7i+9+8OVIe
 O/xN9pQ8vdqgcz89VLFENIQuKgjuUYA/vrDB87RJG1mpX6ir4qIaL/6FSscLXvWl
 CxAtKFyPoZWFc42X2ahQxvntUSUIWhD7la+ix/K+p75p5PRhSOI75MkGjCGHOUd7
 ry2expqFwiE6M1DmiFJaHcahlV+DNp7sNqSCaiBB8dxUxcSE4oP1Q8yBiYWjpQkC
 DqofqZOCg2CPPpsrorY2lNr7XFhHuzIVHX0lRfTgAyMDfxNkmdPVXqwzs8VyzxM=
 =DM26
 -----END PGP SIGNATURE-----
 

THRIFT-5214: Partial rewrite of TFramedTransport

Client: go

While debugging the issue in THRIFT-5214, I original thought that was a
bug in TFramedTransport implementation, so I took some time scrutinize
the TFramedTransport code. Although in the end there's no bug, the
current implementation of TFramedTransport, especially in the Read
function, has some weird handling while at frame boundary, which is both
error-prone and hard to follow (I did found and fixed one bug there in
https://github.com/apache/thrift/pull/1810 before).

The new implementation reads the whole frame into a buffer, which would
use slightly more memory, but it follows the pattern of TFramedTransport
implementation of other languages (e.g. Java), and also the pattern we
handle frame in THeaderTransport. It also reduced the complexity and
weirdness of the frame boundary handling in Read implementation.

This rewrite also removes the print call from library code.