Refactor channel interfaces #1115
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Make MemorySendChannel and MemoryReceiveChannel into public classes, and move a number of the methods that used to be on the abstract SendChannel/ReceiveChannel interfaces into the Memory*Channel concrete classes. Also add a Channel type, analogous to Stream. See: python-triogh-719 Still to do: - Merge MemorySendChannel and MemoryReceiveChannel into a single MemoryChannel - decide what to do about clone - decide whether to add some kind of half-close on Channel - refactor this PR's one-off solution to python-triogh-1092 into something more general.
Codecov Report
@@ Coverage Diff @@
## master #1115 +/- ##
==========================================
+ Coverage 99.51% 99.51% +<.01%
==========================================
Files 102 102
Lines 12518 12526 +8
Branches 953 953
==========================================
+ Hits 12457 12465 +8
Misses 40 40
Partials 21 21
|
Codecov Report
@@ Coverage Diff @@
## master #1115 +/- ##
==========================================
+ Coverage 99.51% 99.51% +<.01%
==========================================
Files 102 102
Lines 12518 12529 +11
Branches 953 950 -3
==========================================
+ Hits 12457 12468 +11
Misses 40 40
Partials 21 21
|
oremanj
reviewed
Jun 21, 2019
| """Attempt to receive an incoming object, blocking if necessary. | ||
|
|
||
| It's legal for multiple tasks to call :meth:`receive` at the same |
There was a problem hiding this comment.
It seems like it would be useful to explicitly document what is and is not guaranteed about tasks calling send() or receive() simultaneously for all Channels. Also maybe something about cancellation safety. If you want to stop guaranteeing that multiple simultaneous receive() works OK, maybe move this text to MemoryReceiveChannel.receive() instead of removing it entirely?
There was a problem hiding this comment.
Hmm, yeah. I'm thinking ahead to "framing channels" that just wrap line-breaking or whatever around a stream, so they'll have the same single-user rule as streams. But that's a good point.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Make MemorySendChannel and MemoryReceiveChannel into public classes,
and move a number of the methods that used to be on the abstract
SendChannel/ReceiveChannel interfaces into the Memory*Channel concrete
classes. Also add a Channel type, analogous to Stream.
See: gh-719
Still to do:
MemoryChannel
refactor this PR's one-off solution to Should the Final and NoPublicConstructor classes inherit from typing.GenericMeta? #1092 into something moredonegeneral.