[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 #23 from Oliver Hunt <oliver at apple.com> ---
(In reply to comment #22)

> > Can you clarify what the caller must do to ensure that the returned pointer continues to point to valid memory? 
> My assumption was that a call to JSValueProtect() on the Typed Array would
> also ensure the pointer remains valid, but I'm not really sure if that's
> actually the case. Maybe Filip Pizlo can chime in: when/how exactly is the
> underlying buffer "pinned"?
> 
> If JSValueProtect() indeed already ensures the pointer remains valid, I
> don't think we need another set of functions to retain/release the data
> pointer. Imho it's obvious that if the JSObject is GC'ed, the pointer will
> become invalid. If you want to hold on to the pointer, hold on to the
> JSObject.
> 

I'm not sure about this - Fil, do we guarantee we won't move a typed array's backing buffer if the referencing object is pinned?

> 
> > Why does getting the data pointer require a byte length?
> I found that if you want to obtain the data pointer of a Typed Array, you
> almost always also need to get the byte length of that data. Note that the
> pointer to the size_t you pass in, is only used for output! Having two
> separate API calls for this seemed wasteful. If you don't need the byte
> length, simply pass NULL instead of a pointer to a size_t:
> void * ptr = JSObjectGetTypedArrayDataPtr(ctx, object, NULL);

I don't believe we have any other api that behaves in this way.
API consistency is important.

> > Why do we use byte length for access but element count for creation?
> JSObjectGetTypedArrayDataPtr() returns a pointer to raw data. If we were to
> return the element count instead of the byte length, you would always need
> to call JSObjectGetTypedArrayType() as well, to figure out how many bytes
> you could access. Using the byte length here greatly simplifies stuff like
> memcpy() to/from own buffers for API users.

r- just based on this API decision.

You're optimizing for a single case (memcpy), over the common case: casting the array of X into an X*.

Mixing and matching what unit the length you're using is a recipe for mistakes.

> Likewise, we use an element count for JSObjectMakeTypedArray() because 
> 1) you know the type of the Typed Array you want to create anyway
> 2) usually you know the number of elements you want to store when creating a
> Typed Array through the API (this is different from being passed a Typed
> Array from JS Land!)
> 3) using a byte length here would be error prone: what if I try to create a
> Uint32Array with a byte length of 5?

Which is why we should always be using the item count. If absolutely necessary you could have a GetByteLength function just as the js api has.

> 
> 
> > How do you create a typed array with a data pointer? Is the input a void*?
> I don't think we need an API for this. Just let JSC handle the data
> allocation and then obtain a pointer to it.
> 
> JSObjectRef array = JSObjectMakeTypedArray(ctx, kJSTypedArrayTypeUint8Array,
> 1024);
> void *dataPtr = JSObjectGetTypedArrayDataPtr(ctx, array, NULL);
> memcpy(dataPtr, myOwnData, 1024);
> 
> Imho it's not worth to complicate the API to avoid a short memcpy() for
> handing over data to JS Land.
Again, optimizing for memcpy is not the right trade off here.

Also this API fails to allow sharing of data allocated elsewhere, that can lead to unnecessary memory copying. Most other data related APIs on OS X allow specifying the external buffer to use -- in fact most APIs take the buffer pointer, and only allocate if that pointer is null.

-- 
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/20151013/a3b43f9b/attachment-0001.html>