[+v8-users]
On Mon, Dec 9, 2013 at 9:37 PM, Dmitry Lomov <[email protected]> wrote: > I think you assume what is (possibly) true for one embedder and > extrapolate to other embedders. Node.js is not our only embedder :) > > > On Mon, Dec 9, 2013 at 9:20 PM, Roman Shtylman <[email protected]> wrote: > >> >> >> >> >> On December 9, 2013 at 3:07:10 PM, Dmitry Lomov >> ([email protected]<//[email protected]>) >> wrote: >> >> 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) >> >> That’s the point of the Weak stuff. The person who first externalizes >> must be the one who understands how to cleanup so there is no “rouge” >> nonsense. Additional users who want to access the data must get a Contents >> from the AB and check IsCollected() or IsEmpty() or something doesn’t >> matter. Yes, I realize they *could* store the data pointer and not get it >> from the Contents ever time but shit this is c++ they could do that if they >> wanted to anyway! What you are preventing is actually doing the memory >> management a clean way instead of preventing some “potential” data* storage >> concern. If it was easy to get the Contents multiple times from the AB then >> a person would be more likely to do that. >> >> Here is an actual example where I encounter this problem: >> >> https://github.com/defunctzombie/libuv.js/blob/master/src/uvjs_fs.h#L416 >> >> If the read call is called with the some buffer that was already >> externalized I would like to re-use it but I cannot. >> >> These bindings don’t have any state setup routines currently because all >> they do is return an ObjectTemplate with these bound methods which means >> they are for others to embed in their shells or environments. With the >> right APIs they would be able to use the externalized pointers just by >> asking the AB for them and if they were already externalized querying if >> they are safe to use (similar to a NULL check if you will). >> > > What I suggest to do here is to implement the API in Node that will let > you get at externalized pointer. After that, it is just: > > shared_ptr<ABBackingStore> data = nodeApi->GetBackingStore(arr); > > Everything else is the same. You can use your favorite or std:: variation > of smart pointers to manage it. > > One thing that is nice about this is that you don't have to worry about > each and every function that tries to externalize memory from ArrayBuffer > about how to create weak callbacks &c. This is done once and for all by > Node API. > > I have no idea how libuv plugs into Node, but I can suggest ways of > accessing Node API even from stateless functions fi you can't already (you > can hang it off v8::Isolate) > > > Hope this helps, > Dmitry > >> >> >> >> >> >> On Mon, Dec 9, 2013 at 8:52 PM, Roman Shtylman <[email protected]> >> 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 <[email protected]> >> 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 >>> [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.
