W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2012

[Bug 18611] New: Blob should support Transferable

From: <bugzilla@jessica.w3.org>
Date: Fri, 17 Aug 2012 22:24:50 +0000
To: public-webapps@w3.org
Message-ID: <bug-18611-2927@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18611

           Summary: Blob should support Transferable
           Product: WebAppsWG
           Version: unspecified
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: File API
        AssignedTo: arun@mozilla.com
        ReportedBy: glenn@zewt.org
         QAContact: public-webapps-bugzilla@w3.org
                CC: public-webapps@w3.org


#17757 was in error.

It makes perfect sense for Blob to be transferable, for the same reasons that
Blob#close is useful: so the UA deterministically knows that the underlying
storage of a Blob can be freed immediately if no other Blobs refer to it.

It would be equivalent to saying:

    worker.postMessage({data: blob});
    blob.close();

but with the consistency of working like everything else that supports
neutering, and giving the same semantics of postMessage.  It's inconsistent to
have to do this differently for Blob and ArrayBuffer, eg. isntead of

    worker.postMessage({data: blob, buffer: arrayBuffer}, [blob, arrayBuffer]);

you have to say

    worker.postMessage({data: blob, buffer: arrayBuffer}, [arrayBuffer]);
    blob.close();

even though as far as script-visible behavior is concerned, transfer and
neutering are the same thing.  To scripts, the transfer argument is simply a
list of large objects that the script no longer needs, indicating that the
browser can optimize for that; whether that optimization actually involves
transfering objects (ArrayBuffer) or just freeing storage (Blob) doesn't
matter.

This also means that you get the same semantics of postMessage: either all of
the items in the transfer list are neutered or none are, instead of the above
which may neuter arrayBuffer but not blob if an exception is thrown by
structured clone.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Friday, 17 August 2012 22:24:51 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:54 GMT