Repository navigation
Need to define error handling of MLNamedArrayBufferViews transfer algorithm #351
Description
Activity
In WebML WG Teleconference – 11 May 2023, group discussed this issue, and @RafaelCintron proposed that
RafaelCintron: we can loop through everything before detaching? to make sure everything can be detached?
… put a pointer to say "this cannot be detached" and only when we know everything can be detached we detach everythingThis ideal sounds great. Thanks Rafael!
This validation loop should ensure WebIDL transfer an ArrayBuffer algorithm would succeed for each array. As far as I can tell, there are three aspects need to be validated:
- The buffer is not SharedArrayBuffer. This check can be done by
IsSharedArrayBuffer(buffer). It is asserted by WebIDL transfer an ArrayBuffer algorithm. - The buffer is not detached. This check can be done by
IsDetachedBuffer(buffer). It is also asserted by WebIDL transfer an ArrayBuffer algorithm. - The buffer's [[ArrayBufferDetachKey]] is undefined, otherwise the DetachArrayBuffer(arrayBuffer [, key]) would throw exception.
For the last check, should it be done by comparing
ArrayBuffer.[[ArrayBufferDetachKey]]directly? I didn't find this assertion in WebIDL transfer an ArrayBuffer algorithm. @domenic , any insights?And Blink's DOMArrayBuffer class seems not to expose
detached_key_, so the implementation may not check the detached key. Did I miss anything? @wacky6- The buffer is not SharedArrayBuffer. This check can be done by
I didn't find this assertion in WebIDL transfer an ArrayBuffer algorithm. @domenic , any insights?
"transfer an ArrayBuffer" will throw if [[ArrayBufferDetachKey]] is not undefined, as explained in the note after it (which refers to the note after https://webidl.spec.whatwg.org/#dfn-detach ).
"transfer an ArrayBuffer" will throw if [[ArrayBufferDetachKey]] is not undefined, as explained in the note after it (which refers to the note after https://webidl.spec.whatwg.org/#dfn-detach ).
That's cool. Thanks!
Because WebNN MLNamedArrayBufferViews transfer algorithm transfers an array of buffers by a loop, we want to avoid this exception when transferring a buffer in the middle of the array, that may leave the early transferred buffers detached. Should we check [[ArrayBufferDetachKey]] is undefined for each buffer in the validation loop?
As there are three checks (if I didn't miss any others) for a successful buffer transferring, if there is a WebIDL algorithm for this check, e.g. an ArrayBuffer is
detachable, that would be extremely helpful.WDTY?
Should we check [[ArrayBufferDetachKey]] is undefined for each buffer in the validation loop?
Yes, I think that would work.
if there is a WebIDL algorithm for this check, e.g. an ArrayBuffer is
detachable, that would be extremely helpful.I'd be happy to review any work to add such an algorithm to Web IDL.
- added a commit that references this issue
on Jul 19, 2024 - added a commit that references this issue
on Jul 19, 2024
According to the steps of the MLNamedArrayBufferViews transfer algorithm in WebNN spec, for each
ArrayBufferView, it transfers the underlyingArrayBufferof the view.However, the
ArrayBuffertransferring algorithm performsDetachArrayBuffer(arrayBuffer [, key]), defined by ECMAScript spec, that would throw a "TypeError" exception if theArrayBuffer.[[ArrayBufferDetachKey]]is notkey(keyis set toundefinedif not present). Because WebNN doesn't setkey, it means theArrayBufferwhose [[ArrayBufferDetachKey]] is set to a value other thanundefinedwould fail, such as the value of WebAssembly.Memory's buffer attribute. For another example, theArrayBufferreturned by WebGPUGPUBuffer::getMappedRange()who sets[[ArrayBufferDetachKey]]to "WebGPUBufferMapping".WebNN spec should define how to handle this exception and what's the impact to the
MLNamedArrayBufferViews. In particular, if the exception occurs when transferring the view in the middle of the loop, what should the implementation deal with the already transferred views, the failing view and the remaining views in theMLNamedArrayBufferViews.This issue was raised by @wacky6 in WebNN Chromium CL review. Thanks Jiewei!