[Webkit-unassigned] [Bug 120112] Typed Arrays have no public facing API

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=120112

--- Comment #15 from Filip Pizlo <fpizlo at apple.com> ---
(In reply to comment #14)
> > JS_EXPORT JSTypedArrayType JSTypedArrayGetType(JSContextRef ctx, JSValueRef value);
> > JS_EXPORT JSObjectRef JSTypedArrayMake(JSContextRef ctx, JSTypedArrayType arrayType, size_t numElements);
> > JS_EXPORT void * JSTypedArrayGetDataPtr(JSContextRef ctx, JSValueRef value, size_t * byteLength);
> 
> The right phrasing here would be:
> 
> JSValueGetTypedArrayType(JSContextRef ctx, JSValueRef value);
> OR
> JSObjectGetTypedArrayType(JSContextRef ctx, JSObjectRef value);
> 
> JSObjectMakeTypedArray(JSContextRef ctx, JSTypedArrayType arrayType, size_t
> numElements);
> 
> JSValueGetTypedArrayDataPtr(JSContextRef ctx, JSValueRef value, size_t *
> byteLength);
> OR
> JSObjectGetTypedArrayDataPtr(JSContextRef ctx, JSObjectRef value, size_t *
> byteLength);
> 
> Why does getting the data pointer require a byte length? Why do we use byte
> length for access but element count for creation?
> 
> It seems like the uncontroversial idea in this API is an unforgeable way to
> create typed arrays using the C and ObjC APIs without having to save the JS
> constructor objects at the start of execution. Sort of like JSObjectMakeDate
> and JSObjectMakeRegExp. I'd like to see a patch that does that part for C
> and ObjC -- it's easy to get that right without solving the hard problem of
> how to get a data pointer.

I actually don't think that the data pointer is a hard problem, and I don't think it's controversial.  We should just do it, and we should just use reference counting - where GetTypedArrayDataPtr() is a retain and some other function is a release - is the answer for lifetime issues.  Another solution is to flip this around and have a JSObjectMakeTypedArrayWithData(context, basePointer, byteLength, type, keep) function.  I believe that the Java equivalent of typed arrays (java.nio.Buffer and friends) takes this approach in its native API.  I'd be happiest if we did both.

Note that none of the usual complaints about such an API work here.  You can't argue that the GC might move the memory, because our typed array implementation already supports pinning.  We can pin any typed array backing store at any time, and this is well-tested functionality since it already happens in WebCore.  You can't say that it's weird for native code to have a pointer to what is sort of a managed object, because our typed array implementation is deliberately designed around giving a pointer to the memory to native code and WebCore already uses this.  Also, array buffers already support ref counting in addition to GC marking, so that makes it even simpler to just expose a ref-countable raw buffer to API clients.  So, we should support some variant of this API, provided that we pick some sensible answer to questions like "how long does the memory live" when you call GetTypedArrayDataPtr().  Does anyone have an argument against having a ReleaseDataPtr() API that is the release 

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150922/1363ad6b/attachment.html>