I think global here is referring to the global HandleScope and not the owning object. I suspect that by holding it with a persistent handle you globalize (free it's ties to C++ scope dependent handles like Local) the object. According to the Embedder's Guide:
"Persistent handles are not held on a stack and are deleted only when you specifically remove them. Just like a local handle, a persistent handle provides a reference to a heap-allocated object. Use a persistent handle when you need to keep a reference to an object for more than one function call, or when handle lifetimes do not correspond to C++ scopes...." "...A persistent handle can be made weak, using Persistent::MakeWeak, to trigger a callback from the garbage collector when the only references to an object are from weak persistent handles." The comments and documentation leave me with the impression that when one object holds another it does not do so using a weak persistent handle, and thus the garbage collector is prevented from invoking the callback. This gets into internals which I am not too keen on (I am just a user like yourself), but there are developers on this list that can jump in should you like to know more. Best, Alfred On Sun, Feb 21, 2010 at 12:17 PM, deadmorous <[email protected]> wrote: > Thank you very much, Alfred. > This seems to be exactly what I asked for. :) One thing I still don't > understand is the description of "object" parameter in > WeakReferenceCallback, saying "the weak global object to be reclaimed > by the garbage collector". Why "global"? What if the object was a > property of some other object, and the property was then removed? > > Best regards, > Deadmorous > > On 21 фев, 19:32, Alfred Rossi <[email protected]> wrote: >> I apologize, that was supposed to say "The garbage collector is NOT >> guaranteed..." >> >> Best, >> Alfred >> >> On Sun, 2010-02-21 at 11:31 -0500, Alfred Rossi wrote: >> > You're looking for Persistent::MakeWeak. You can use MakeWeak to specify >> > a callback to be invoked when the object is about to be garbage >> > collected. >> >> > You should be careful about building in an alternate way to free your C >> > ++ objects. The garbage collector is guaranteed to be run, ever, even >> > after the context has been disposed. >> >> > See this for more details: >> >http://stackoverflow.com/questions/173366/how-do-you-free-a-wrapped-c... >> >> > Best, >> > Alfred >> >> > On Sun, 2010-02-21 at 08:24 -0800, deadmorous wrote: >> > > Hello, >> > > I'm trying to use V8 to expose functionality of my app to JS. >> > > In my app, there are objects with properties and methods, organized as >> > > a tree of properties; >> > > object instances can be created and added to the tree. >> > > I understand how to expose my properties using V8 interceptors, and >> > > think that it's correct to expose my >> > > methods as properties of prototypes. Further, I would like objects to >> > > be creatable from JS code, >> > > so I would expose my native constructors to JS. It happens that I have >> > > to have a duality between my instances >> > > and JS instances. In my app, I would put a handle to JS instance >> > > corresponding to my instance; >> > > and vice versa, I can put a pointer to my instance into corresponding >> > > JS instance, by using >> > > Object::SetInternalField(), and using a value of type External. >> >> > > Now to my question. What I really don't understand - how can I know >> > > that a JS object is being destroyed? >> > > I really need to know that, at least in order to destroy my instance >> > > attached to the one being destroyed in JS. > > -- > v8-users mailing list > [email protected] > http://groups.google.com/group/v8-users -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
