[x] stream: error multiple iterators

[ronag]

Throw if creating multiple async iterators from the same stream.

Refs: #28997

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• documentation is changed or added
• commit message follows commit guidelines

[ronag]

@mcollina @lpinca There might be a valid case for multiple iterators when doing nested for loops. What do you think?

for (const x of stream) {
  for (const y of stream) {
  }
}

An alternative to this PR could be to always return the same iterator if one has already been created?

[mcollina]

@mcollina @lpinca There might be a valid case for multiple iterators when doing nested for loops. What do you think?

The internal loop is going to exhaust the stream anyway.

[mcollina]

Good work! I've left a few things to change.
I would like to know what @benjamingr and @devsnek think about this one, as it's a tricky case.

[mcollina]

This test would have to be split in two. The previous code verified that iterating on an ended stream completes - this would have to be tested without the first for await. Then , we should add a new test about the ERR_STREAM_ITERATOR_EXISTS error.

[benjamingr]

I am not convinced we should do this - there are cases where creating multiple iterators might be valid and there are cases where I'd want to create an iterator - consume part of the stream, throw it away - then create another iterator to consume the rest of the stream.

[benjamingr]

const cursor = database.query(...).cursor();
for await(const item of cursor) {
  if (item === 'special-item') {
    // found first special item
   report(item);
  }
}

for await(const item of cursor) {
  // do something with all future items
}

In this case the user might think they have a single iterable but they actually have two.

[mcollina]

I am not convinced we should do this - there are cases where creating multiple iterators might be valid and there are cases where I'd want to create an iterator - consume part of the stream, throw it away - then create another iterator to consume the rest of the stream.

This is not currently possible. Adding break within an for await  will call .destroy()  on the stream to prevent leakages, and I think that's correct.

[benjamingr]

This is not currently possible. Adding break within an for await will call .destroy() on the stream to prevent leakages, and I think that's correct.

Oh yeah, I remember that :D

That is correct behavior at a second glance, a break does return which finishes the stream.

not sure about this anymore.

[mcollina]

not sure about this anymore.

Unfortunately this is complex topic. Think about it a bit more, and let us know!

[benjamingr]

@mcollina do we actually have a choice though? We don't have any concept of multiple readables for a resource in core (do we?) - and if someone wants to build a package that tees to support this then sure.

Is there actually an alternative other than throwing? (or erroring later)

[ronag]

I'll sort out the PR comments once we have more of a consensus.

[mcollina]

Is there actually an alternative other than throwing? (or erroring later)

I think returning the same iterator might be considered an option.

[benjamingr]

I guess that makes sense since it aligns with having the behaviours people expect for the same Readable for the same data source.

[ronag]

The internal loop is going to exhaust the stream anyway.

You could have a break... oh no... that will destroy the stream. So in this case we would need to reference count the number of createIterator vs destroy iterator requests, before we destroy the stream?

[benjamingr]

You could have a break... oh no... that will destroy the stream. So in this case we would need to reference count the number of createIterator vs destroy iterator requests, before we destroy the stream?

Doing refcounting would just be confusing IMO, I am fine with either this behavior (throw) or Matteo's suggestion (same iterator).

[ronag]

Doing refcounting would just be confusing IMO,

It's just as confusing without refcounting :D. I totally got the nested behaviour wrong.

[devsnek]

Generally I like this (we do the same thing in web streams), but we should have a way to release the lock somehow.

[devsnek]

Also for the above point about wanting multiple consumers, the general approach from other languages and from web streams is to tee the origin stream with a buffered intermediary (https://developer.mozilla.org/en-US/docs/Web/API/ReadableStream/tee)