W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

[Bug 13799] Should Transferables be transfered even when postMessage fails?

From: <bugzilla@jessica.w3.org>
Date: Wed, 19 Oct 2011 00:49:33 +0000
To: public-webapps@w3.org
Message-Id: <E1RGKLd-0003eI-Rx@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13799

Ian 'Hixie' Hickson <ian@hixie.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #3 from Ian 'Hixie' Hickson <ian@hixie.ch> 2011-10-19 00:49:33 UTC ---
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the tracker issue; or you may create a tracker issue
yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: see diff given below
Rationale: Concurred with reporter's comments.

kbr: I don't understand why you need to do anything to ArrayBufferViews when
transferring ArrayBuffers. Just have the ArrayBufferView's byteOffset,
byteLength, etc, properties return 0 when the underlying ArrayBuffer has been
neutered. (Also, don't forget to actually say that the old ArrayBuffer is
neutered — see the HTML spec for MessagePort to see what I mean.) Similarly,
in the "Interactions with the Structured Cloning Algorithm" you don't need to
have any special case for ArrayBuffer, that's already handled (because it's
Transferable), and the code for ArrayBufferView just needs to say that it
recurses to the ArrayBuffer (which won't do anything straight away since the
new objects are placeholders at this point now) and then creates a new object
with the same values, or something like that. Since the actual transfer happens
after the cloning, the values don't get zeroed out until after the clone
happens — and if you define the ArrayBufferView interface's attributes as
returning zero if the buffer is neutered, independent of the cloning algorithm,
then you don't have to worry about that happening during cloning either. Ping
me if this isn't clear.

-- 
Configure bugmail: http://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 Wednesday, 19 October 2011 00:49:37 GMT

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