On May 11, 2008, at 4:08 PM, Aaron Boodman wrote:
On Sun, May 11, 2008 at 3:02 PM, Maciej Stachowiak <[EMAIL PROTECTED]>
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
