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?
On December 9, 2013 at 6:26:38 AM, Dmitry Lomov ([email protected]) 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 <[email protected]> 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 <[email protected]> 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 [email protected] 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out. -- -- v8-users mailing list [email protected] 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out. -- -- v8-users mailing list [email protected] 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
