- From: Maciej Stachowiak <mjs@apple.com>
- Date: Sun, 11 May 2008 16:22:46 -0700
- To: Aaron Boodman <aa@google.com>
- Cc: Chris Prince <cprince@google.com>, "Web API WG (public)" <public-webapi@w3.org>, Ian Hickson <ian@hixie.ch>
On May 11, 2008, at 4:08 PM, Aaron Boodman wrote: > On Sun, May 11, 2008 at 3:02 PM, Maciej Stachowiak <mjs@apple.com> > wrote: >> Both of these can be addressed by the APIs (including the worker >> transfer >> mechanism) making a copy, which can use a copy-on-write mechanism >> to avoid >> actually making a copy in the common case. > > Ok, so just so I'm clear, does the following example snippet > accurately reflect how you propose that things work? I'm not sure I am following it all exactly, but I think yes. Variable assignment would not trigger any copy-on-write behavior, since it is still the same object. Passing to an API (including sendMessage to a worker) would make a copy-on-write virtual copy. > > > var req = new XMLHttpRequest(); > req.open("GET", "example", true); > req.onreadystatechange = handleResult; > req.send(null); > > function handleResult() { > if (req.readyState != 4) return; > > var b1 = req.responseByteArray; > var b2 = b1; > assert(b1 === b2); // they refer to the same object > > // print the contents of the array > for (var i = 0; i < b1.length; i++) { > print(b1[i]); > } > > b1[0] = 42; > assert(b2[0] == 42); > > var worker = window.createWorker("worker.js"); > worker.sendMessage(b1); // branches b1 > b1[0] = 43; // modification does not affect what got sent to worker > } > > // worker.js > worker.onmessage = function(b) { > assert(b[0] == 42); > }; > > >> I'm still not convinced that immutability is good, or that the >> ECMAScript >> ByteArray proposal can't handle the required use cases. > > Here's one additional question on how this would work with ByteArray. > The read API for ByteArray is currently synchronous. Doesn't this mean > that with large files accessing bytearray[n] could block? If the ByteArray were in fact backed by a file, then accessing bytearray[n] could lead to part of the file being paged in. However, the same is true if it is backed by RAM that is swapped out. Even accessing uninitialized zero-fill memory could trap to the kernel, though that's in general not as bad as hitting disk (whether for swap or file bytes). I can see how you may want to have an object to represent a file that can be handed to APIs directly, but that has only an async read interface for JS. However, I am pretty sure you would not want to use such an object to represent binary data returned from an XHR, or the pixel contents of a <canvas>. After all, the data is already in memory. So perhaps files need a distinct object from other forms of binary data, if we wanted to enforce such a restriction. Regards, Maciej
Received on Sunday, 11 May 2008 23:23:26 UTC