Re: Blobs: An alternate (complementary?) binary data proposal (Was: File IO...)

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