Absolutely. Otherwise I would not have been required to create my autoDestroy class to handle file closing.
I was referring to memory, not resources. Memory will be freed on application exit. Conceptually, however, it is not v8's place to garbage collect the objects. The only time running a final garbage collection would make sense is at application exit (not context exit), and the only things that are, in theory, v8's to free are it's own objects and values. v8 does not own the native C++ objects; C++ owns them. V8 simply owns handles to pointers (externals) to C++ objects. The MakeWeak fubction is meant specifically to tell you when JavaScript is no longer using the object; it is not meant to destroy the object. Why should it waste valuable CPU time at application exit, causing it to take as long to close as Adobe InDesign, Testing each and every object to see if it MIGHT be referenced by any weak handles, so that it can tell you that the object is no longer being used by JavaScript -- something you should already know, since the application is exiting. When NOT at application exit, none of this is a concern, because, as long as you are still using v8, the garbage will be collected eventually; and, if necessary, you can make it occur more often so the scripting uses less memory. Alex Sent from Alex's iPhone On Mar 9, 2009, at 6:06 PM, Stephan Beal <[email protected]> wrote: > > On Mar 9, 11:57 pm, Stephan Beal <[email protected]> wrote: >> That's not the way C++ does destruction. A C++ destructor may free >> resources, and dtors are not called at app exit if the objects are on >> the heap (which nearly all JS/Native wrapped objects are). That leads >> to db handles, file handles, etc. which don't get closed in a well- >> defined fashion (i.e. could lead to corruption). > > Here's a silly example, but an example nonetheless: > > Let's say i have a TempFile class which extends some File type but has > the feature that it deletes itself at destruction. In v8 that class > will sometimes be leaving temp files laying around. On Unix platforms > this can be worked around by deleting the file directly after opening > it (that's legal), in which case the handle is valid until the app > exits (and the filesystem may then free the space since it has no FAT > entry). On Windows we can't do that (we can't even rename an opened > file), so this isn't reliable from v8 on those platforms. > > But the point applies more generally: arbitrary classes may allocate > arbitrary resources (even via a third party, such as some type of > object/Corba server), and not destructing may leave those resources > dangling in places outside the immediate application. > > > --~--~---------~--~----~------------~-------~--~----~ v8-users mailing list [email protected] http://groups.google.com/group/v8-users -~----------~----~----~----~------~----~------~--~---
