Adding a note here about an API example which I thought was interesting but communicated off the list.
ArrayBuffer::Contents::Collect(); This would call the "Free" method on the Allocator used to create the data in the first place. This exists because passing the allocator to a plugin or library may be unfeasible and kinda pointless since the Contents knows what Allocator it was allocated with. This would avoid inconsistencies. Possibly also having an IsCollected() method. Would also be good to have a way to re-get externalized Contents from the ArrayBuffer after they have been externalized but not Neutered. This can't easily be done now because determining which internal fields to use for what purpose is not standardized and would thus present problems across plugins or disjoint libraries. This can be resolved by the ArrayBuffer class since it is the mediator. This is the major pain point with externalization at the c++ level right now; not being able to have a known way to get back at this externalized information even if it is still valid. Not saying that ArrayBuffer needs to expose the data*, but allowing multiple access to the Contents would solve this as long as the Contents have not been collected. And the safe way to collect Contents would be via Collect() call which would make the contents invalid as well as use the appropriate Allocator without guessing or other additional setup routines. On Sunday, December 8, 2013 10:56:14 PM UTC-5, Roman Shtylman 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.
