#1103 Refactor Multi.toFlow() to avoid blocking - Mutiny1

[heubeck]

• Switching from channelFlow to callbackFlow brings simplification
• Blocking issue (kotlin Multi<T>.asFlow() blocking the thread #1103) was caused by buffering of the channel that underlies the Flow, solved by explicit switching to an unlimited channel that doesn't buffer.

[heubeck]

this test became flaky, the onFailure was sometimes propagated before flow.collect retrieved the second item - forcing a context switch helped. need to observe this further on.

[jponge]

Let's see progress on #1105

[jponge]

@heubeck You can sync from #1105 👍

[heubeck]

@heubeck You can sync from #1105 👍

really sure?
Every use of the toFlow needs to be re-compiled, I'm afraid there might be transient usages in libraries that get the bytecode-incompatible version by downstream dependency management and break at runtime.
I'll do it, if you say so, just mentioning.

[jponge]

Hum you have a point.

[jponge]

So the fix for 1.x could be to keep the method, and perform unlimited buffering, and update the docs.

WDYT?

[heubeck]

So the fix for 1.x could be to keep the method, and perform unlimited buffering, and update the docs.

WDYT?

convinced 😊
Will also add a statement for that thing to the mutiny 2 docs as it's not obvious.