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

Support supplying collection context elements #320

Closed
wants to merge 4 commits into from

Conversation

JakeWharton
Copy link
Member

@JakeWharton JakeWharton commented Apr 11, 2024

Closes #314


  • CHANGELOG.md's "Unreleased" section has been updated, if applicable.

// Use test-specific unconfined if test scheduler is in use to inherit its virtual time.
@OptIn(ExperimentalCoroutinesApi::class) // UnconfinedTestDispatcher is still experimental.
val unconfined = scope.coroutineContext[TestCoroutineScheduler]
?.let(::UnconfinedTestDispatcher)
?: Unconfined

val output = Channel<T>(UNLIMITED)
val job = scope.launch(unconfined, start = UNDISPATCHED) {
val job = scope.launch(collectContext + unconfined, start = UNDISPATCHED) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

I had thought that overriding the dispatcher here would be a big reason folks would want to use this. I do think it would be surprising if I tried to use that parameter for that purpose and found it didn't work.

Suggested change
val job = scope.launch(collectContext + unconfined, start = UNDISPATCHED) {
val collectDispatcher = collectContext[CoroutineDispatcher] ?: unconfined
val job = scope.launch(collectContext + collectDispatcher, start = UNDISPATCHED) {

Copy link
Member Author

Choose a reason for hiding this comment

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

We should throw if you try to do that. There's no reason to change the dispatcher on which we write into the channel, and anything other than unconfined would open up the potential for correctness problems since you make things like expectMostRecentItem() (or whatever it's called) racy.

Copy link
Collaborator

Choose a reason for hiding this comment

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

There's no reason to change the dispatcher on which we write into the channel

If this is so (and I think I agree, even though I hate unconfined - we don't do anything inside collect, apart from call trySend, so any dispatcher hop on emit can only be bad), then maybe the right change is this:

flowOn(collectContext).collect { output.trySend(it) }

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, that seems nice. Should the parameter be called flowContext? flowOnContext? Something else?

Copy link
Member Author

Choose a reason for hiding this comment

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

I'm pretty sure this whole feature isn't needed. Just call flowOn!

Base automatically changed from jw.more-stuff.2024-04-10 to trunk April 12, 2024 14:59
@JakeWharton JakeWharton deleted the jw.collect-context.2024-04-10 branch April 12, 2024 15:08
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.

Support supplying CoroutineContext to be used in flow collection
2 participants