Convert the Worker API to use Flow instead of using its own Emitter type. #435
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
zach-klippenstein
force-pushed
the
zachklipp/flow-workers
branch
from
768789a
to
99ea5e7
Compare
zach-klippenstein
requested review from
rjrjr,
vRallev,
afollestad,
Blisse,
kirillzh and
christiandeange
kirillzh
approved these changes
Jul 1, 2019
zach-klippenstein
force-pushed
the
zachklipp/flow-host
branch
from
a61f5fa
to
171db17
Compare
rjrjr
approved these changes
Jul 2, 2019
kotlin/workflow-core/src/main/java/com/squareup/workflow/Worker.kt
Outdated
Show resolved
Hide resolved
kotlin/workflow-core/src/main/java/com/squareup/workflow/Worker.kt
Outdated
Show resolved
Hide resolved
zach-klippenstein
force-pushed
the
zachklipp/flow-workers
branch
from
99ea5e7
to
a73a091
Compare
zach-klippenstein
force-pushed
the
zachklipp/flow-workers
branch
from
a73a091
to
543e569
Compare
…ype. The old `Worker` API was just an over-simplified copy of the `Flow` API. Now that most core Flow APIs have graduated to "experimental" status, it doesn't make sense to copy them. Using Flow directly has a few benefits: - One less reactive streams contract to keep in your head (while the Worker API was _similar_ to Flow, it was less strict and likely to diverge more over time). - We get access to all the built-in Flow operators. - Out-of-the-box integration with various reactive streams libraries. - Since Workers are always consumed as channels, we get lots of optimizations when the source is also a channel, or knows how to make one. Flow also does operator fusion for buffering and context-switching operators. - The Kotlin Worker API now matches the Swift one almost exactly - the only difference is that the streams used by the Swift library don't have backpressure.
zach-klippenstein
force-pushed
the
zachklipp/flow-workers
branch
from
543e569
to
045e5be
Compare
zach-klippenstein
added a commit
that referenced
this pull request
Jul 6, 2019
When Workers were converted to flow in 045e5be (#435), buffering was introduced. `produceIn` will, by default, use the `BUFFERED` value to configure its channel's capacity, which resolves to the "default" buffer size. This value is more than zero, which means buffering was accidentally introduced into workers where it shouldn't be.
|
This closed #298 as well. |
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.
The old
WorkerAPI was just an over-simplified copy of theFlowAPI.Now that most core Flow APIs have graduated to "experimental" status, it
doesn't make sense to copy them. Using Flow directly has a few benefits:
API was similar to Flow, it was less strict and likely to diverge more
over time).
when the source is also a channel, or knows how to make one. Flow
also does operator fusion for buffering and context-switching operators.
only difference is that the streams used by the Swift library don't
have backpressure.