-
Notifications
You must be signed in to change notification settings - Fork 151
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
=str Make decider caculation lazy #627
Conversation
So I don't know what to really think of this, I know that in other cases we use |
Is this just guess? Because it's |
@jxnu-liguobin Noop, I think it was not lazy just because out of sight in the first place. |
@@ -1402,8 +1402,7 @@ private[stream] object Collect { | |||
new GraphStageLogic(shape) with InHandler with OutHandler { | |||
override def toString = s"MapAsyncUnordered.Logic(inFlight=$inFlight, buffer=$buffer)" | |||
|
|||
private val decider = | |||
inheritedAttributes.mandatoryAttribute[SupervisionStrategy].decider | |||
private lazy val decider = inheritedAttributes.mandatoryAttribute[SupervisionStrategy].decider |
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.
Can we make this a def
? In most places in this source file, this is a def
.
The def
means no synchronize block. lazy val
s come with the overhead of having synchronize
in the generated byte code.
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.
def
will do recaculation, and that should be avoid.lazy val
will only do synchronization the first time, and the supervision strategy method is expected to be quick for calculation, so even the undering Thread is a VirtualThread, it will not cause any problem either.
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
You don't need to close a PR to rerun the tests. Go to the broken build and there are buttons to rerun failed builds. You can rerun the one build that failed instead of having every single build run again. |
the streamRefspec is flasky |
Motivation:
We don't expect much exception throws, and it's
lazy val
inMapAsync
, so better to keep those two the same.Result:
Consistent with
MapAsync
.