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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Sep 22 12:55:28 PDT 2015


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

--- Comment #20 from Filip Pizlo <fpizlo at apple.com> ---
(In reply to comment #19)
> > Referenced.  For example the "keep" argument could be interpreted as:
> > 
> > keep=true: we call the system free() on the original void* when we decide to
> > free the buffer.
> > 
> > keep=false: we don't free the original void* buffer when we free the array
> > buffer, and the only way that the client can be sure that we no longer want
> > the backing data is when they destroy the VM.
> 
> These options don't seem very good to me in a general purpose API.
> 
> We can't assume that our client used malloc. They might have used new, mmap,
> objc_createInstance, or a custom allocator.
> 
> Requiring a valid pointer for the lifetime of the VM is a difficult model to
> program with. For example, we couldn't use that model in the browser, or in
> the audio processing context being discussed on webkit-dev.
> 
> > Having a free callback would be even better.
> 
> This seems more reasonable to me.
> 
> It would be nice if we didn't have to reinvent a generic API for "referenced
> counted data pointer". Perhaps we can write this API in terms of
> CFMutableDataRef and NSMutableData.

Hmmm, that's a good point.  NSData already has everything we need:

- We can return a NSData or CFDataRef when someone asks for a raw pointer to a typed array.  The NSData would have a deallocator that decrements our internal buffer ref count.

- We can create an array buffer when given a NSData. It would be easy to modify our internal ArrayBuffer code to make it capable of calling a custom destructor and/or just [object 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/0bcf4f6a/attachment-0001.html>


More information about the webkit-unassigned mailing list