- From: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
- Date: Fri, 24 Aug 2012 15:19:43 +0300
- To: Nils Dagsson Moskopp <nils@dieweltistgarnichtso.net>
- Cc: whatwg@whatwg.org
On Fri, Aug 24, 2012 at 3:04 PM, Nils Dagsson Moskopp < nils@dieweltistgarnichtso.net> wrote: > Jussi Kalliokoski <jussi.kalliokoski@gmail.com> schrieb am Fri, 24 Aug > 2012 13:23:03 +0300: > > >[…] > > > > My first idea was that if you set a property called "chunkSize" on > > the XHR, it would start dispatching an event called "onchunk" > > whenever a chunk of that size has been loaded. That event would > > contain a property "chunk" that would be an array buffer containing > > that data. However, I'm having second thoughts on that approach as it > > is likely to produce a lot of garbage. > > Can you elaborate on the nature of the lot of garbage you are expecting? > Yes. The "chunk" property on the event would be a fresh ArrayBuffer, so unless it gets bound somewhere, it becomes garbage. > > Instead, my refined idea is that you'd set a "chunk" property on the > > XHR to an ArrayBuffer, and each time a chunk of the size of the > > "chunk" was ready, it would set the values of the "chunk" property > > accordingly and the "onchunk" event would be dispatched. > > Maybe I have not understood it, but at first glance that approach seems > prone to race conditions. What happens if the next chunk is ready while > the “onchunk“ event for the last one has not been processed? Does the > “chunk” property get overwritten and the previous chunk's data is lost? > This is not the case, let me clarify. Setting the chunk would be scheduled in the event loop, so unless the event loop is leaking, no race conditions should happen. Cheers, Jussi
Received on Friday, 24 August 2012 12:20:10 UTC