Skip to content
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

Restore timeouts with wallclock time #140

Merged

Conversation

jingibus
Copy link
Collaborator

@jingibus jingibus commented Sep 3, 2022

Addresses remarks on #130.

@jingibus jingibus force-pushed the wphillips/2022-09-03/timeouts-wallclock-time branch from 5c1a9a9 to 25d520d Compare September 3, 2022 15:04
Copy link
Member

@JakeWharton JakeWharton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great stuff. Dense, so it took a while to understand, but I think it makes sense.

build.gradle Outdated Show resolved Hide resolved
src/commonMain/kotlin/app/cash/turbine/Turbine.kt Outdated Show resolved Hide resolved
src/commonMain/kotlin/app/cash/turbine/Turbine.kt Outdated Show resolved Hide resolved
src/commonMain/kotlin/app/cash/turbine/channel.kt Outdated Show resolved Hide resolved
src/commonMain/kotlin/app/cash/turbine/channel.kt Outdated Show resolved Hide resolved
src/commonMain/kotlin/app/cash/turbine/coroutines.kt Outdated Show resolved Hide resolved
src/commonTest/kotlin/app/cash/turbine/FlowTest.kt Outdated Show resolved Hide resolved
@JakeWharton
Copy link
Member

JakeWharton commented Sep 9, 2022

Also somewhere centralized we should probably have a require(timeout.isPositive) to forbid 0 and negative values (with a test!)

@JakeWharton JakeWharton mentioned this pull request Sep 9, 2022
@jingibus jingibus force-pushed the wphillips/2022-09-03/timeouts-wallclock-time branch from 25d520d to 441546b Compare September 15, 2022 15:23
@jingibus
Copy link
Collaborator Author

Also somewhere centralized we should probably have a require(timeout.isPositive) to forbid 0 and negative values (with a test!)

Missed this in my revision pass yesterday!

@JakeWharton
Copy link
Member

Didn't realize you were doing these changes in a fork. Sent you an invite for write access so you can do them directly in the repo in the future.

@jingibus jingibus force-pushed the wphillips/2022-09-03/timeouts-wallclock-time branch from 441546b to 7daab67 Compare September 15, 2022 16:33
Comment on lines 113 to 115
val timeoutJob = launch(Dispatchers.Default) { delay(timeout) }

select {
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure why this garbage is passing spotless, but it is

@jingibus jingibus force-pushed the wphillips/2022-09-03/timeouts-wallclock-time branch 3 times, most recently from cfc5abb to 3ecc453 Compare September 15, 2022 19:29
Comment on lines 108 to 112
if (timeout != null) {
withTurbineTimeout(timeout, block)
} else {
block()
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do this instead of passing the timeout into ChannelTurbine?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. Passing the timeout into ChannelTurbine wraps every single receive() in a withContext call, while this only requires one
  2. Doing this means that the timeout is also applied to any other Turbines run within this block.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think either of those things apply here. The block is only a call to flow.collect { channel.trySend(it) } and never runs user code (unless they're using Turbine inside flow { }). This coroutine's context isn't shared by the caller interacting with the Turbine instance.

I'll write a quick test for it.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oof, you're right. We probably don't even need to be hooking up the timeout at all here: the timeout isn't even accessed in this context.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Issue addressed; new tests in FlowTest and FlowInScopeTest

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We probably just wrote the same tests. Signing off for a few hours.

@jingibus jingibus force-pushed the wphillips/2022-09-03/timeouts-wallclock-time branch from 3ecc453 to 7fba2d1 Compare September 15, 2022 20:47
@jingibus jingibus merged commit f118449 into cashapp:trunk Sep 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants