stream: iter() should yield every so often.

[carllerche]

stream::iter() should yield every so often and participate in the coop functionality. However, I'm not sure if it should consume budget on every iteration.

Another option would be to consume budget every ~25 steps... but that would require adding state to the stream. Yet another strategy would be to make consuming budget be weighted. So stream::iter would consume 1 unit every iteration but reading data would consume much more (1 unit per n bytes? not sure)

[jonhoo]

I actually don't think iter() should participate in coop budgeting, at least not in that way. It should be left to the underlying resources that feed the underlying streams. What you may want to do though is make it so that iter() detects if a significant number of the underlying streams have returned Pending in a single iteration, it'll check if the budget has been exhausted, and if so return Pending itself rather than poll all the remaining streams (since they will likely also return Pending).

[carllerche]

iter() is an underlying resource IMO. An "underlying resource" is the leaf async fn, which iter is.

I also have seen people hit this specific problem, i.e. use an unbounded (or very large) iter, map it to a stream, and it hangs the executor. Given this, it seems good to fix.

[jonhoo]

Ohhhh, sorry, I read this as the async stream iter thing that came up a while back (the impl Stream over a collection of impl Stream). This is a Stream over a regular Iterator. Yes, then I agree that it is an underlying resource and should participate in budgeting. I actually also think it's fine to consume one "unit", at least for the time being. I don't think we have a good enough grasp on what budgeting units should be at the moment, so "one" is probably okay. Maybe there's an argument for having a "coop::squander" which temporarily removes the budgeting for a particular scope?

[carllerche]

I'm fine starting w/ this if you are.