- From: Jungkee Song <notifications@github.com>
- Date: Thu, 24 Nov 2016 21:36:46 -0800
- To: w3c/ServiceWorker <ServiceWorker@noreply.github.com>
- Message-ID: <w3c/ServiceWorker/issues/882/262884112@github.com>
@jakearchibald, let me refer to the examples in your last comment as "fetched streams case", "JS-generated streams case", "JS-generated streams case with waitUntil", and "pipeTo after waitUntil promise resolve case". I was confused with "fetched streams case" in our chat yesterday. (@jakearchibald's last comment started to clarify that discussion.) The steps that enqueue chunks to fetchEvent's potential response in respondWith(r) run **in parallel**. So it doesn't hold SW open until the whole body is handled. And in Handle Fetch, SW basically waits until the fetchEvent's wait to respond flag is unset. That means SW stays up until the fetchEvent's potential response's reference is copied to the internal variable that will be returned to fetch. Hence, I don't think we have a problem with this case. Also, for "JS-generated streams case", "JS-generated streams case with **waitUntil**" is the pattern that we made our consensus on in the last f2f. So, I think we can close this issue when "pipeTo after waitUntil promise resolve case" is clarified. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/ServiceWorker/issues/882#issuecomment-262884112
Received on Friday, 25 November 2016 05:37:28 UTC