| 10:25 | <annevk> | tobie: could it be that there are changes to PR Preview that are not in GitHub? |
| 10:26 | <annevk> | tobie: we no longer see the warnings with our specifications, but there's nothing that suggests we would have removed them |
| 10:26 | <annevk> | tobie: although now that I ask you, I am starting to suspect Bikeshed as that is often a source of regressions |
| 10:40 | <annevk> | TabAtkins: could there have been a change in Bikeshed that would mean that warnings no longer show up everywhere? |
| 11:05 | annevk | files https://github.com/tabatkins/bikeshed/issues/1818 |
| 16:45 | <annevk> | Domenic: JakeA: what's a good label for AbortController/AbortSignal? "topic: aborting"? |
| 16:45 | <JakeA> | annevk: works for me |
| 21:07 | <croraf> | Is this a push or pull underlying source: https://www.typescriptlang.org/play?#code/DYUwLgBAlhC8EAYDcAoFBjA9gOwM6QCcQBDAE2ICNQBlMI4gWzgmxAHcIAlE8qkW+gwA82AK4MKIAgD4AFAG80ECPmIEwsrNjqZgoAgEoIi5cq35o2qQDdiwZrnABJKwVvBZso7GnGIWnT0pADoQbABHURAo2SgDJGgAakSEgF8AGggARgRc+KVTRzAAFSgGEExRDS84XxNTM1A1FzAbO1jXd3yGsxxA-WD0YExHL1QGjOzcvPGIVJRU-IwcC3pSKWY1yho6EgZggHNwbjIpMeW8XRBg4YPZNakDC9WeZhqfYxRey9AbzDuAORrKDYA4A7oQL4QB4EYJrLzBMAACzCsihylk7ii3 |
| 21:07 | <croraf> | jq-hWVz+dyxIHi0AAZhBMXYosFSDgQHBYPAyXZHEZ5NCeGM5nMofl5vD4kA |
| 21:11 | <croraf> | https://jsfiddle.net/croraf/a8r9hojz/ |
| 21:12 | <andreubotella> | croraf: https://streams.spec.whatwg.org/#creating-examples |
| 21:12 | <andreubotella> | compare some of the push examples with 10.4 |
| 21:18 | <croraf> | this is the push underlying source? |
| 21:18 | <croraf> | it generates data no matter if I listen or not |
| 21:19 | <croraf> | I mean it enqueues no matter if I read it or not |
| 21:19 | <andreubotella> | right |
| 21:23 | <andreubotella> | hm, now I'm wondering what happens if you have a push source without backpressure but there's no one listening |
| 21:23 | <andreubotella> | for a user-created stream, it can't block because it'd deadlock the tab, so it must throw, I guess |
| 21:25 | <croraf> | to remove a chunk from the "queue" you must read it with the reader, any other way? |
| 21:25 | <andreubotella> | I don't think there's any other way, but streams isn't my area of expertise |
| 21:26 | <croraf> | i thought you are an expert in streams :D |
| 21:26 | <andreubotella> | I/O queues perhaps, readable/writable streams not so much :) |
| 21:32 | <croraf> | push ReadableStreams seem very simple, the set up underlying source enqueues and the reader reads. |
| 21:33 | <andreubotella> | until you add backpressure, that is |
| 21:33 | <andreubotella> | then it's not so simple anymore |
| 21:38 | <Domenic> | andreubotella: the queue just keeps getting larger forever |
| 21:38 | <Domenic> | croraf: the queue can also get empty if the stream errors, or if the reader calls reader.cancel() |
| 21:39 | <Domenic> | Agreed that dealing with backpressure for push streams makes them harder |
| 21:39 | <croraf> | And what about when you make a tee. And you keep consuming one stream, but not the other. |
| 21:40 | <croraf> | Does it tee() make 2 buffers |
| 21:41 | <andreubotella> | Domenic: the queue getting larger forever doesn't seem ideal, but I guess if no one's reading from the stream it's very likely that it was dropped, in which case the GC could collect the items |
| 21:42 | <Domenic> | croraf: tee() makes two streams, each of which have their own queue, indeed. |
| 21:45 | <croraf> | Domenic, thanks. What happens with the queue of the original stream then. Let's say the queue has 1000 items in it already, when you make a tee. |
| 21:47 | <Domenic> | croraf: the chunks will generally stay in the original stream's queue. read() from either branch will pull an item from the original stream's queue into the two branches' queues (one of which will immediately be delivered to the caller of read()). |
| 21:48 | <Domenic> | So e.g. if you do 500 read()s on branch1 and 250 reads on branch2, the end result will be 500 chunks in originalStream, 0 chunks in branch1, and 250 chunks in branch2. |
| 21:49 | <croraf> | Why didnt the original stream get its chunks deleted? |
| 21:49 | <croraf> | Oh, it had 1000 at first |
| 21:49 | <croraf> | as per my example |
| 21:49 | <Domenic> | Indeed, only the chunks which someone asked for got pulled into the branches |
| 21:50 | <croraf> | Even after the tee has been created, the original source will still push on the originalStream's queue? |
| 21:51 | <Domenic> | Yes |
| 21:54 | <croraf> | thanks |
| 22:16 | <croraf> | Well, tee-ing a stream will consume data from its queue even though the original stream is not read with a reader. |
| 22:17 | <croraf> | So this is another way to remove chunks from the queue. |
| 22:18 | <croraf> | Which also makes me wonder what happens if you pipe the original ReadableStream to a WriteableStream or through a TransformStream |
| 22:33 | <Domenic> | Both teeing and piping use readers internally |
| 22:40 | <croraf> | That is step 3 in https://streams.spec.whatwg.org/#readable-stream-tee ? |
| 22:43 | <Domenic> | Correct |
| 22:47 | <croraf> | I'm checking https://streams.spec.whatwg.org/#readable-stream-pipe-to 15, which describes how the pipeTo works. |
| 22:49 | <croraf> | Basically pipeTo reads from ReadableStream (with push source) as soon as there is something available in the queue and writes to the WriteableStream. |