[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 #31 from Filip Pizlo <fpizlo at apple.com> ---
(In reply to comment #30)
> Thanks for the in-depth explanation, Filip!
> 
> So it seems an additional JSObjectReleaseTypedArrayDataPtr(ctx, object, ptr)
> function would be absolutely necessary.
> 
> Unfortunately I understand way to little about the innards of JSC to
> implement the pining/retaining of the backing store myself. I'm not sure
> what steps exactly JSObjectGetTypedArrayDataPtr() would need to take.

JSArrayBufferView* view = jsDynamicCast<JSArrayBufferView*>(object);
if (!view)
    .... wrong object type
ArrayBuffer* buffer = view->buffer(); // this pins the buffer, and we know that it will remain pinned so long as you hold a +1 on the ArrayBuffer.
buffer->ref(); // do the +1 thing

The JSObjectReleaseTypedArrayDataPtr method could then just do something like:

JSArrayBufferView* view = jsDynamicCast<JSArrayBufferView*>(object);
if (!view)
    .... wrong object type
ArrayBuffer* buffer = view->buffer();
buffer->deref(); // tell the GC that we don't need pinning anymore

I believe that if you do it this way, it guarantees safety while ensuring that this API stays out of the way of our future VM hacks.

> 
> On the other handJSObjectReleaseTypedArrayDataPtr() would only need to
> ensure that the pointer really belongs to object and then "unpin"/release
> the object's backing store, right?

Yeah.

> 
> 
> Again, I don't see myself fit to actually implement this in JSC, but I
> believe the API we now arrived at is pretty solid. Namely:
> 
> 
> Create a TypedArray:
> JSObjectRef JSObjectMakeTypedArray(JSContextRef ctx, JSTypedArrayType
> arrayType, size_t numElements);
> 
> Query type:
> JSTypedArrayType JSObjectGetTypedArrayType(JSContextRef ctx, JSObjectRef
> object);
> 
> Query byte length and element count:
> size_t JSObjectGetTypedArrayByteLength(JSContextRef ctx, JSObjectRef object);
> size_t JSObjectGetTypedArrayNumElements(JSContextRef ctx, JSObjectRef
> object);
> 
> Obtain a pointer to the array's data (retains the pointer):
> void * JSObjectGetTypedArrayDataPtr(JSContextRef ctx, JSObjectRef object);
> or
> void * JSObjectGetTypedArrayDataPtr(JSContextRef ctx, JSObjectRef object,
> size_t &byteLength);
> 
> Release pointer to the array's data:
> JSObjectReleaseTypedArrayDataPtr(ctx, JSObjectRef object, void * dataPtr);
> 
> 
> Is there anything else the API needs to cover?
> 
> Let me also state again that I don't think a method to create a Typed Array
> with a pointer (that was allocated elsewhere and would not be copied) is
> necessary. Current users of Typed Arrays within Webkit (XMLHttpRequest,
> WebSockets, WebGL) seem to get along without it. I.e. always letting JSC
> take care of the allocation doesn't seem to be a problem.

OK.

Please also consider our earlier suggestion to have the API revolve around a C object that is something like:

struct Data {
    void* base;
    size_t size;
    void (*destructor)(void*);
};

Where JSObjectGetTypedArrayDataPtr would actually return a Data*.  You could imagine being able to then remove JSObjectReleaseTypedArrayDataPtr and instead mandate that the user calls data->destructor(data->base) when done.  This makes the API seem less ad hoc, IMO.  On OSX, Data* could be replaced with just CFDataRef.  In the future, having the notion of "Data" would make it easy to wrap an ArrayBuffer around a Data.  I know that you don't want it, but others might.  FWIW, I want this.

I know that you don't care about OSX APIs, and I totally get that.  But I have to care. :-)  It would be great to come up with something that we can admit into our API on OSX and that also serves your purposes.

-- 
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/20151015/e2ed9d41/attachment-0001.html>