- From: Gregory Terzian <notifications@github.com>
- Date: Sun, 31 May 2020 10:24:17 -0700
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Sunday, 31 May 2020 17:24:29 UTC
So I ended doing this in https://github.com/servo/servo/pull/25873. From this experience, I think it's perhaps not really important to "queue a task" explicitly when manipulating the stream from fetch. In Servo this is indeed done via queuing a task(the "fetch" process sends an IPC message to "script", and a task is queued on the event-loop by the IPC "router" thread in the "script" process), however the task queuing is really just a way to "enter the relevant script state", in this case via the message-passing infra of task-queuing. So if Chromium does this "synchronously", I think at the end of the day it doesn't really matter, and I see no need to mandate "task-queuing" to do this(the operation of reading from the stream doesn't seem to require putting on an explicit task-queue). I guess the only thing that matters is that the read operation doesn't actually happen in parallel to the event-loop, in the sense that you can't be executing tasks and reading chunks at the very same time(since that could be noticeable from script)? Should we close this one? -- 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-636501407
Received on Sunday, 31 May 2020 17:24:29 UTC