3) Its me with rxjava `startWith` and flow `onStar...

# coroutines

[ursus]

3)
Its me with rxjava startWith and flow onStart again

CoroutineScope(SupervisorJob() + <http://Dispatchers.IO|Dispatchers.IO>).launch {
	flowOf(1)
		.onStart { emit(0) }
		.collect {
			stateFlow.value = it
		}
}

-- is equivalent to:
Observable.just(1)
	.startWith(0) <---
	.subscribeOn(<http://Schedulers.io|Schedulers.io>()) <---
	.subscribe {
		behaviorRelay.accept(it)
	}

-- In rx I use:
Observable.just(1)
	.subscribeOn(<http://Schedulers.io|Schedulers.io>()) <---
	.startWith(0) <--- swapped
	.subscribe {
		behaviorRelay.accept(it)
	}

is this doable somehow in flow? (to not have the onStart emit coming from io thread)

[gildor]

Isn;t in another thread it was already explained that onStart has different semantics and how to implement iperator which works on startWith?

[gildor]

onStart doesn’t prevent upstream flow to emit, it’s just a side effect which may emmit too

[gildor]

https://pl.kotl.in/WkHhWS4O1

[ursus]

How has it different semantics? In the previous thread where you and Jake replied, the issue basically was I used lambda.asFlow, wrongly. when correctly turning suspend fun to flow it worked as expected

[gildor]

I don't think so, because onStart doesn't guarantee order of emits! So if you onStart is slower, it will return later than your lambda

[gildor]

So it works just because onStart is faster in your case

[ursus]

Ok didnt expect it wasnt guaranteed to be first, thanks