Re: [whatwg/fetch] ReadableStream and in-parallel/event-loop integration question (#976)

> We do it synchronously by entering the relevant script state when we want to call read().

Ok, could that operation be wrapped inside a queued task instead?

Last question: Specifically for a request body, when in the lifetime of  a fetch do you do you do this? 

> I was also worried about what would happen if a higher-priority task blocked the queued task, but I'm not sure that's relevant.

The way I read the spec, is that:

- [`transmit-body`](https://fetch.spec.whatwg.org/#concept-request-transmit-body) is called from parallel steps of a fetch.
- It then acquires a reader, and a read a first chunk from the stream as part of Steps 3 and 4.
- It then starts, on step 5, a new set of "in-parallel" steps to actually pull the data from the resolved promised and transmit them over the network(where step 5.1.1 is "Wait for read to be fulfilled or rejected"), and read another chunk(via a new promise, see step 5.2.3) until the stream is done.

So step 5 is a bit like starting a "transmit body worker" that runs in parallel to already "in-parallel" fetch steps.

So if step 3-4 were to happen from a queued task, using the networking task-source, those steps could then queue steps back on the "transmit body worker", which could be defined as a [parallel-queue](https://html.spec.whatwg.org/multipage/infrastructure.html#parallel-queue).

I think step 5.2.3, the "read another chunk" part, could be moved to the queued task, which should simply keep reading chunks(each time via a promise so not blocking the event-loop) and send each chunk back to fetch by queuing steps on the parallel queue. 

So in such a setup, the "general" fetch steps could just keep running, since those happens on a different set of "in-parallel" steps from the conceptual "transmit-body worker". The worker actually just blocks until the read promise resolves, and then blocks again until the chunk is fully transmitted over the network.

Then from the event-loop perspective, if the networking task-source is used, that task could be delayed due to task-queue prioritization, however it would retain it's overall ordering versus the other fetch tasks, and delaying this task wouldn't otherwise block the main fetch.

This still leaves the question of whether this would fit into Blink and Geko's current approach.

-- 
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/fetch/issues/976#issuecomment-561006287