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

[Public WebGL] zeroing length on transfer

I'm glad to see excitement about being able to transfer ArrayBuffers:


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.


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