<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Typed Arrays have no public facing API"
href="https://bugs.webkit.org/show_bug.cgi?id=120112#c31">Comment # 31</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Typed Arrays have no public facing API"
href="https://bugs.webkit.org/show_bug.cgi?id=120112">bug 120112</a>
from <span class="vcard"><a class="email" href="mailto:fpizlo@apple.com" title="Filip Pizlo <fpizlo@apple.com>"> <span class="fn">Filip Pizlo</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=120112#c30">comment #30</a>)
<span class="quote">> 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.</span >
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.
<span class="quote">>
> 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?</span >
Yeah.
<span class="quote">>
>
> 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.</span >
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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>