okay, I might have a brain fart and its possible I misread one thing and raised the issue.prematurely. If someone is able to confirm that the current API of Flow is sufficient to to create:

• two generators in one thread which would work with interleaved calls to their next methods, and
• many generators, each in separate thread, which would work when calls to their next method interleave,
  then things are most probably ok and just resolve this issue.

I will hopefully find some time soon to get back to the kata and try out some ideas which I think I missed before.

Regarding this question: https://www.codewars.com/kata/59e7c7e5fc3c49d93f0000d3/discuss#605e6ee0983870002f0cfabb

This should be explained in the description. I was scrathing my head since the first time I saw this kata and wondered how to squeeze generators in a way they do not get in a way of each other into required API of Flow and could not come up with anything, just to read here that it's not necessary.

The fact that this requirement does not have to be satisfied is counter-intuitive because now the kata relies on the fact that generators are not fully independent.

Added a test like you suggested.

I think it is possible to test if a solution is lazy enough.

I've increased the number of iterations in the tests. Do you know some way to prevent such solutions from passing? I think it's impossible to restrict this since there will always be some upper bound of how many values can be consumed/tested before hitting the time limit.

Added.

my solution keeps timing out on the real tests, and i'm not really sure where the bottleneck is in my code. help?

(also, a bunch of existing solutions just got trashed by the null yields test... rip)

thanks, i've added your new tests. i've also added a note to the description warning that yielded values may be null

this kata isn't really meant to test for multiple threads of execution, but i suspect using static variables to store generator-specific data will likely fail in cases with multiple generators anyways

a good implementation probably should allow for unrelated generators to run in parallel threads, but this kata doesn't require or test for that

You could also test yielding null-values, with and without combining with yieldFrom.

When a generator is done, next() should return null. But if yielding null the generator might not be done.