conn: yield received plaintext from a lending iterator - #3149
Conversation
Benchmark resultsInstruction countsSignificant differencesClick to expand
Other differencesClick to expand
Wall-timeSignificant differencesClick to expand
Other differencesClick to expand
Memory usageKey:
Significant differencesClick to expand
Additional informationCheckout details:
|
ctz
left a comment
There was a problem hiding this comment.
I suggest we do the first two commits separately, as aren't really controversial
9034a9c to
2771cd7
Compare
9773fad to
939c298
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3149 +/- ##
==========================================
- Coverage 95.35% 95.31% -0.04%
==========================================
Files 99 99
Lines 23183 23143 -40
Branches 671 672 +1
==========================================
- Hits 22106 22059 -47
- Misses 925 928 +3
- Partials 152 156 +4 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
f7a9e8f to
615aa41
Compare
| #[test] | ||
| fn streamowned_can_be_created_for_client_and_tcpstream() { | ||
| type _Test = StreamOwned<ClientConnection, TcpStream>; | ||
| type _Test = StreamOwned<ClientConnection, ServerSide, TcpStream>; |
There was a problem hiding this comment.
this is wrong. (can the bound be put on the struct?)
There was a problem hiding this comment.
What do you mean by putting the bound on the struct?
There was a problem hiding this comment.
Bare in mind first my confidence with rust type golf is low. Can trait Connection require each impl exposes its Side: SideData value as an associated item? Then it doesn't need to be restated here, and any references to it can be C::Side instead.
There was a problem hiding this comment.
Bare in mind first my confidence with rust type golf is low. Can
trait Connectionrequire each impl exposes itsSide: SideDatavalue as an associated item? Then it doesn't need to be restated here, and any references to it can beC::Sideinstead.
It could but I think it would preclude the use of dyn Connection which we're using in some places, which makes it a larger change at the least (and probably triggers some of the monomorphization things you tend to dislike).
| let iter = server.process_new_packets(&mut server_input); | ||
| let mut received = Vec::with_capacity(16); | ||
| let state = iter.handle_all(&mut received).unwrap(); | ||
| assert!(state.peer_has_closed()); |
There was a problem hiding this comment.
assert_eq!(received, b"from-client!"); here or similar -- it is important that peer_has_closed() does not overtake appdata.
in addition tests that do not consume the whole of iter should see no peer_has_closed() here for the same reason.
There was a problem hiding this comment.
assert_eq!(received, b"from-client!");here or similar -- it is important thatpeer_has_closed()does not overtake appdata.
Done.
in addition tests that do not consume the whole of
itershould see nopeer_has_closed()here for the same reason.
Did you see concrete instances of this?
|
With your approval, going to merge this. Happy to take further feedback of course, and noting to
next. |
@ctz early feedback?