Repeating my off-list replies on-list now (sigh... please don't do this) The behind the API for ArrayBuffer is that once AB is externalized, the embedder manages the book-keeping for that data (maybe using shared_ptr or some other mechanism).
Therefore the API that allows "re-externalization" of ArrayBuffer contents will create a side-channel for the embedder (if you have a v8::AB in your hand, you can get at memory the embedder manages without the rest of the embedder knowing - so embedder might have carefully managed the access to memory with smart pointers or similar, but a rogue plugin just thwarted that architecture by freeing data willy-nilly) On Mon, Dec 9, 2013 at 8:52 PM, Roman Shtylman <shtyl...@gmail.com> wrote: > 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. > This is a bad idea for the reasons described above. > > 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. > Key point here is that ArrayBuffer is not a mediator of access to its backing store. ArrayBuffer participates in managing that memory with the embedder. The real mediator of access to that memory is the embedder. So it is with the embedder that any libraries or plugins need to negotiate the patterns of memory access. V8 is not in the business of providing plugin system for its embedders. Hope this helps, Dmitry On Mon, Dec 9, 2013 at 8:52 PM, Roman Shtylman <shtyl...@gmail.com> wrote: > 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 > 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 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.
