- From: <bugzilla@jessica.w3.org>
- Date: Fri, 17 Aug 2012 22:24:50 +0000
- To: public-webapps@w3.org
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 UTC