Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Issue 73313 ArrayBuffers not preserved across Worker Threads
Starred by 18 users Reported by jeffschiller@google.com, Feb 17 2011 Back to list
Status: Fixed
Owner:
Closed: Aug 2011
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Restricted
  • Only users with Commit permission may comment.



Sign in to add a comment
Chromium	11.0.671.0 (Developer Build 74782)
WebKit	534.20 (trunk@78443)
V8	3.1.3
User Agent	Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_4; en-US) AppleWebKit/534.20 (KHTML, like Gecko) Chrome/11.0.671.0 Safari/534.20
Command Line	 /Applications/Chromium.app/Contents/MacOS/Chromium --allow-file-access-from-files --flag-switches-begin --flag-switches-end

Other browsers tested: None

What steps will reproduce the problem?
1. Save the two attached files to a local directory
2. Invoke Chromium with --allow-file-access-from-files
3. Browse to chrome-file-ab.html
4. Open the JavaScript console and refresh

I see the following output:

ab.toString() = [object ArrayBuffer]
ab.byteLength = 123
Inside worker.js: ab.toString() = [object Object]
Inside worker.js: ab.byteLength = 123

What is the expected result?

I expect the "type" of the object passed in the event to the worker to be preserved.  In other words the third line of output should be "[object ArrayBuffer]", not "[object Object]".

This causes problems because apparently new Uint8Array() requires an actual ArrayBuffer, not an ArrayBuffer-like object.


 
worker.js
194 bytes View Download
chrome-file-ab.html
339 bytes View Download
Comment 1 by kbr@chromium.org, Feb 17 2011
Labels: -Area-Undefined Area-WebKit
Status: Assigned
Apologies. No work has been done yet on passing these objects across workers.

The current semantics of how ArrayBuffers and views would be passed across workers are not ideal, as an allocation on the destination side and a copy of the data would be involved. We strongly want to enable zero-copy semantics, while retaining ECMAScript's shared-nothing semantics. We have a design for this which we plan to propose in the next revision of the typed array spec. The discussions will probably begin at the end of this month, once WebGL 1.0 has been released. See https://www.khronos.org/webgl/public-mailing-list/ for where the discussions will likely begin.

Comment 2 Deleted
Comment 3 Deleted
Comment 4 by levin@chromium.org, Jun 14 2011
Cc: levin@chromium.org dslomov@chromium.org
Labels: Feature-Workers
Comment 5 by sethladd@google.com, Aug 31 2011
Hi,

Curious if there was any more discussion on this. Was a (planned) solution arrived at?
This bug has been fixed since, at least, Chrome 13.  Just verified it.
Comment 7 by levin@chromium.org, Aug 31 2011
I believe the original bug has been fixed (perserving the type).

The stuff that kbr mentioned is still under development.

Comment 8 by levin@chromium.org, Aug 31 2011
Status: Fixed
fwiw, it was done here: http://trac.webkit.org/changeset/91300

Woops - my bad, I had forgotten to run with --allow-file-access-from-files so wasn't invoking the worker :)

It's fixed in Chrome 15 and not fixed in Chrome 13.
FYI the zero-copy/transfer-of-ownership semantics change is being worked on here:

https://bugs.webkit.org/show_bug.cgi?id=65209
Project Member Comment 11 by bugdroid1@chromium.org, Oct 13 2012
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member Comment 12 by bugdroid1@chromium.org, Mar 11 2013
Labels: -Area-WebKit Cr-Content
Project Member Comment 13 by bugdroid1@chromium.org, Apr 6 2013
Labels: -Cr-Content Cr-Blink
Sign in to add a comment