Re: [whatwg/streams] Allow stream reader cancel() method to return bytes from queue instead of discarding them. (#1147)

> I want exactly this behavior, but it does not work this way in current Chrome. "finalReadPromise" is immediately resolved with _{ value:undefined, done:true}_ and nothing is read from the port at all.
> I send a lazy stream of 1 byte containing a sequence number every 50-100 ms.

I'd have to see a larger example but are you sure that when this code runs the data has already been received and hasn't already been read? If the next sequence number hasn't been received yet then there's nothing in the queue and `{ value:undefined, done:true }` is the expected result. If you know that the device will send something every 50-100 ms and want to be sure that you'll receive it why not wait for it to be received and then cancel the stream?

Backing up though because maybe I don't understand what it is you are trying to accomplish at a higher level: Why are you canceling the stream?

The only reason to cancel a stream is a) you are closing the port or b) you want to discard any queued data and start over with whatever the device sends next. From what you are saying about getting 1-2% data loss it sounds like you are running your snippet in a loop and are losing 1-2% of the data you are expecting to receive. This is expected because in addition to discarding data in the ReadableStream's queue it also tells the operating system and hardware to flush its buffers, which means that if the data arrives at just the right time it won't be read and will instead be discarded. There's no reason to run this kind of code in a loop however. If you want to read continuously from the device just use the same reader and keep calling read().

In essence, if you don't want to lose data then don't call cancel(). I'd like to understand why you are calling cancel() in the first place because it is probably the wrong solution for the problem you are trying to solve.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/issues/1147#issuecomment-882981447