On Wed, Jun 12, 2013 at 6:48 PM, Jim Acquavella <[email protected]>wrote:
> Thanks Mike M! My solution above does seem to currently work, but the > fact that Sven states this won't be guaranteed to work in the future is > disappointing. I expect the javascript objects in the heap that reference > my C++ objects to be cleaned up when I quit my application. In doing so, I > want my C++ objects freed. To me this seems like basic resource accounting > that I expect v8 to support. > Take it from one who's been there and back and there and back again... AFAIK it is not technically possible for v8 to safely call arbitrary client-side destructors in an arbitrary order. Supports we have two bound natives, the first one has a native level pointer to the second one, but the relationship is one way (the second doesn't know about the link). v8 comes along (hypothetically) and goes to call their dtors because it's philosophically the right thing to do. The order of their destruction will likely be arbitrary (based on their position in the gc'd memory block, or whatever), and let's assume it deletes the second one first. When it cleans up the first value, that value now holds a stale pointer to a destroyed value. Blammo. Post-main() segfault. That same problem applies to non-deterministic gc in general, not just at v8 shutdown, and is one of the reasons one always needs to (==should) add a destroy() (or similar) method to bound natives when they have strict lifetime requirements. My canonical example is the DB driver and the statements it prepare()s, where the statement objects _must_ be freed before their owning DB is. :/ -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal -- -- 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.
