On Mon, Dec 9, 2013 at 3:22 PM, Roman Shtylman <shtyl...@gmail.com> wrote:
> Ok, and how would one influence the fixing or changing of the API to suite > a use case which seems currently not possible without additional hacks? > Clearly stating the use case claimed to be impossible, with justification as to why it is important might help. Note that Blink uses this API for ArrayBuffer implementation, so that must be a use case not covered by the usage in Blink - which might be a tough sell ;) Dmitry > > > On December 9, 2013 at 6:26:38 AM, Dmitry Lomov > (dslo...@chromium.org<//dslo...@chromium.org>) > wrote: > > Note that ArrayBuffer API is experimental and we might change it in the > future. The below reflects what we ship currently. > > > On Mon, Dec 9, 2013 at 4:56 AM, Roman Shtylman <shtyl...@gmail.com> > wrote: > >> A few things are unclear to me after trying to use the ArrayBuffer api >> from v8 3.23.10 >> >> The first inconsistency I find is the disconnect between an initialized >> ArrayBuffer allocated via the globally set allocator and one that you have >> then externalized. It seems there is no good way to get this global >> allocator and thus properly know how to cleanup the ArrayBuffer::Contents >> once you you have them. >> > > The embedder should provide the allocator to V8 prior to V8's > initialization (using v8::V8::SetArrayBufferAllocator). So if you embed V8. > you should know your allocator. There is no default allocator; there can be > only one allocator in the system; any time you get an ArrayBuffer::Contents > (via ArrayBuffer::Externalize call) the memory returned by > ArrayBuffer::Contents::Data() is guaranteed to be allocated by > ArrayBuffer::Allocator::Allocate call. > > >> >> The other difficult aspect is the inability to get the externalized >> contents again once you have gotten them once. This makes sense in the >> context of "externalization" but what I would find very useful is just >> access to the data pointer for the array buffer and let it continue to >> manage the lifetime of the memory. >> > > This is by design: once the memory is externalized, the embedder assumes > ownership of ArrayBuffer's memory. We push the burden of keeping > relationship between externalized data pointers and array buffer objects to > the embedder. > Here is an example of that that is probably simpler than full-blown Blink > bindings: > https://code.google.com/p/chromium/codesearch#chromium/src/gin/array_buffer.h > > So ArrayBuffer API is restricted by design, driven mainly by the desire to > carefully control who owns memory when. We could consider loosing it up a > bit later, but we have been bitten by embedder bugs too many times in the > past, so with this new design we started in a very controlled state. > > Hope this helps, > Dmitry > > > On Mon, Dec 9, 2013 at 4:56 AM, Roman Shtylman <shtyl...@gmail.com> wrote: > >> A few things are unclear to me after trying to use the ArrayBuffer api >> from v8 3.23.10 >> >> The first inconsistency I find is the disconnect between an initialized >> ArrayBuffer allocated via the globally set allocator and one that you have >> then externalized. It seems there is no good way to get this global >> allocator and thus properly know how to cleanup the ArrayBuffer::Contents >> once you you have them. >> >> The other difficult aspect is the inability to get the externalized >> contents again once you have gotten them once. This makes sense in the >> context of "externalization" but what I would find very useful is just >> access to the data pointer for the array buffer and let it continue to >> manage the lifetime of the memory. >> >> Allowing the array buffer to manage the lifetime has the nice benefit of >> using the correct allocator and re-using the memory if I have calls that >> want to do so; right now it is not possible to easily re-use the memory >> without some clever hacks. We already have a system for increasing the >> lifetime of a handle (persistents) so externalizing just to access the data >> and ensure it is not deleted too soon doesn't seem like a relevant api. >> >> tl;dr; >> 1. ArrayBuffer::Contents could be inconsistent with global ArrayBuffer >> allocator >> 2. No way to reuse array buffer memory since externalize can only happen >> once >> -- >> -- >> v8-users mailing list >> v8-users@googlegroups.com >> http://groups.google.com/group/v8-users >> --- >> You received this message because you are subscribed to the Google Groups >> "v8-users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to v8-users+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- > -- > v8-users mailing list > v8-users@googlegroups.com > http://groups.google.com/group/v8-users > --- > You received this message because you are subscribed to a topic in the > Google Groups "v8-users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/v8-users/whHPAIhfMu8/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > v8-users+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
