Conversation
| Alice.nodeParams | ||
| .modify(_.channelConf.expiryDelta).setTo(CltvExpiryDelta(147)), | ||
| Alice.nodeParams | ||
| .modify(_.relayParams.privateChannelFees.feeProportionalMillionths).setTo(2345) | ||
| .modify(_.channelConf.expiryDelta).setTo(CltvExpiryDelta(147)), |
eclair-core/src/test/scala/fr/acinq/eclair/channel/states/e/NormalStateSpec.scala
Show resolved
Hide resolved
eclair-core/src/test/scala/fr/acinq/eclair/integration/basic/ZeroConfAliasIntegrationSpec.scala
Outdated
Show resolved
Hide resolved
eclair-core/src/test/scala/fr/acinq/eclair/router/ChannelRouterIntegrationSpec.scala
Show resolved
Hide resolved
eclair-core/src/test/scala/fr/acinq/eclair/integration/basic/ZeroConfAliasIntegrationSpec.scala
Show resolved
Hide resolved
| def waitFor(duration: FiniteDuration): Unit = { | ||
| val now = TimestampMilli.now() | ||
| eventually(PatienceConfiguration.Timeout(duration * 2), PatienceConfiguration.Interval(50 millis)) { | ||
| assert(TimestampMilli.now() - now > duration) | ||
| } |
There was a problem hiding this comment.
Are you sure this actually achieves something? The calling thread will still be blocked right?
There was a problem hiding this comment.
No it shouldn't, this should be using a spin lock (or something equivalent) and should release the thread after each test (so that other tests can run on that thread between checks), whereas Thread.sleep blocks the thread for the whole duration for everyone.
I haven't actually verified this, but it was the behavior on .NET and the JVM is highly similar, so I expect this to be true.
There was a problem hiding this comment.
According to the doc of eventually, it attempts the check then sleeps (I assume with Thread.sleep) for the interval duration, then rinse & repeat. So it's not as good as I hoped, but it's still better than Thread.sleep, because instead of blocking the thread for the whole duration, we block it for smaller chunks, which regularly gives the opportunity for the task scheduler to run something else on this thread.
There was a problem hiding this comment.
Yes, but I think this saves thread time for the additional thread that executes whatever code is inside the eventually. The caller thread still has to wait. Maybe I'm completely wrong.
There was a problem hiding this comment.
I don't think there is an additional thread that executes the code in the eventually, I believe that most of the time it will just be executed by the caller thread (especially since it doesn't contain a future)?
This is a PR on #2224 to improve some of the tests.