[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 #32 from Dominic Szablewski <dominic.szablewski at gmail.com> ---
(In reply to comment #31)
> 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.

Thanks! I assumed that there would be more to it :) I noticed that ArrayBuffer also has pin() and unpin() methods. This seems to be used when transfer() is called, but the underlying data is not free()ed until the ArrayBuffer is released - it remains safe to use even when it's not pinned. So I'm unsure if pin() & unpin() need to be called as well.


> 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.

Yeah, I think returning a struct would make it a cleaner API. However, to stay consistent with the rest of JSC, it should probably work more like JSStringRef. I.e.:

typedef struct OpaqueJSData* JSDataRef;

JS_EXPORT JSDataRetain(JSDataRef data);
JS_EXPORT JSDataRelease(JSDataRef data);
JS_EXPORT void * JSDataGetBytesPtr(JSDataRef data);
JS_EXPORT size_t JSDataGetLength(JSDataRef data);

JS_EXPORT JSDataRef JSObjectGetTypedArrayData(JSContextRef ctx, JSObjectRef object);

This would also make it easy and very obvious to have a JSObjectGetTypedArrayCFData function as well, just like JSStringRefCF.h does it.

However, the name JSObjectGetTypedArrayData doesn't make it clear that you have to release the JSDataRef again. In fact, according to the CF ownership policy it implies that you don't have to release() it. Naming it analogous to the String functions (JSObjectGetTypedArrayDataCopy) follows the create rule, but is extremely confusing in that it makes it sound like the whole data bytes are copied. I have no idea what the right phrasing would be here.


I'm sorry for abusing the bugtracker for discussion about the implementation. Is there a better place to discuss this?

My hope two years ago was that some of the core contributors would be interested in implementing this, as it's a huge endeavor for me to get up to speed on the style and contribution guidelines, implement and test the changes, build a patch, commit it and get it reviewed - all as a private hobby. Sorry if I'm getting on your nerves here with my questions.

-- 
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/20151016/1b50393f/attachment-0001.html>