[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] zeroing length on transfer



On Sat, Dec 10, 2011 at 1:28 PM, Dave Herman <dherman@mozilla.com> wrote:
>
> I'm glad to see excitement about being able to transfer ArrayBuffers:
>
>    http://updates.html5rocks.com/2011/12/Transferable-Objects-Lightning-Fast
>
> I'm concerned about one aspect of the API, though: zeroing out an ArrayBuffer's length when it's been transferred. The programming hazard of transferring ownership is that your program may still contain references to the object you've transferred. These could either be direct references to the buffer object itself, or indirect references through other views on that buffer. This could come up because a newbie programmer doesn't know what transfer means, or it could come up simply due to ordinary logical errors in a program. Stuff happens. :)
>
> The question is, what happens to your program when this bug occurs? With length-zeroing, at some arbitrary point later in the program you try to index into the buffer or one of its views and its length has changed to zero, so you just get undefined. It's quite possible at this point that the undefined just propagates even further, and it's some time *even later* that something goes wrong. Now your problem is extraordinarily hard to track down.
>
> If instead, an ArrayBuffer goes into a separate "transferred" state, then indexing into it could raise an error with an error message specialized for this particular kind of error: "ArrayBuffer has been transferred to a Worker" or something like that. Then the newbie programmer can Google the error message, and the seasoned programmer quickly realizes that s/he was accidentally using a reference to the wrong buffer. No silent masking of the error with undefined, no delaying the error till later.
>
> I have additional questions about the Worker API, but I'll post that message (haha) to public-webapps.
>
> Thanks,
> Dave

Hi Dave,

Sorry for the delay in replying. I've been on "build cop" duty the
past four days and swamped.

For background, early in the development of the typed array
specification, the views used to throw exceptions -- specifically, for
out-of-range accesses. The rationale was, as you point out, to provide
obvious and early error reporting. However, after extensive discussion
in the working group, this behavior was removed. The reason is that it
is incompatible with ECMAScript's, and therefore Web IDL's, handling
of indexed properties. Because typed arrays are fixed length, an
attempt to store a value into an index outside the supported property
indices first converts the index to a string, and then sets the
property named by that string to the value. (The same is done for
normal ECMAScript arrays when indexed with negative numbers.)

In this context, throwing exceptions for the previously supported
property indices after a transfer differs in behavior from normal
ECMAScript operation. It also differs from how MessagePorts behave
after being transferred. Calling postMessage on a MessagePort that has
been transferred is a no-op; it doesn't throw an exception [1]. I
certainly understand your point that throwing exceptions may ease
debugging, however.

It boils down to a matter of taste. I personally like the current
semantic that the payload of the ArrayBuffer is removed during a
transfer operation, and that after a transfer, it and all views behave
as though they never had any storage backing them. In your proposal,
the only way to detect that an ArrayBuffer has been transferred would
be to try indexing its views and watching for exceptions. The current
behavior allows applications to test the length of the buffer or views
to see if they have gone to zero.

If you still feel strongly that the behavior should be changed,
consider the fact that implementations of transferring ArrayBuffers
have only just started to appear. I think that we should gain some
development experience with the current semantics. If it turns out
that the current behavior is too error-prone, it can certainly be
revisited.

-Ken

[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#message-ports

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------