On Mon, Nov 30, 2009 at 5:43 PM, Jens Alfke <[email protected]> wrote:
> That said, I think a second issue has crept into this discussion: of > disposing external refs when V8 exits completely. As mentioned earlier, this > shouldn't generally be necessary because V8 exits when the process exits, in > which case most external resources get torn down along with the process > (file handles, sockets, etc.) > Database connections, for example, must be properly destructed in order to guaranty proper semantics, e.g. that some session isn't being held open on the remote side for a long time. > This can be an issue with apps Key word - apps. i do A LOT of binding in v8: http://code.google.com/p/v8-juice/ and not one line of it is an application. i write libraries, and as a library author i cannot control what the application is doing. Almost every single class i have bound to JS as part of that project needs a dtor call in order to guaranty proper semantics. That includes i/o object wrappers, DB handles, ncurses window handles (especially when there are parent/child relationships between the windows), etc. Okay, there are two exceptions in all of my use cases: the libexpat and libcurl wrappers behave a well-defined manner if their objects are destroyed by app exit as opposed to a proper dtor. All others do not. > that need to tear down V8 without exiting the process. In that case, > though, the native code could keep its own collection of all native > resources that are bound to V8 objects, and after closing down V8 it can > iterate over all remaining resources and close them. > That work is necessary because, IMO, of v8's and Chrome's requirements being so closely tied. i.e. because Chrome doesn't want v8 to clean up properly ("because it takes too long"), _i_ have to spend dozens of hours coding those features myself (all in all, it _has_ been dozens of hours over the past year). Those dozens of hours are MUCH more than any time Chrome would have needed to shut down if v8 would force a GC at exit. That's what pisses me off the most about this behaviour - that i'm having to do this work for the sake of an application _other_ than the one i'm working on. Another alternative (I believe) would be to repeatedly call V8's low-memory > handler until it returns false, which should wring out all possible > collectible memory, including weak references. > == unreliable hack which might work/not work in any given v8 version. > I'm sure you're correct as measured by number of projects (there's surely > more than one other project in the world using V8), but I'm pretty sure > you're incorrect as measured by number of active users (Chrome is up to 30 > million last I heard.) > That's very likely true. i'd certainly bet on it. > This is a classic dilemma of open source projects: the design is driven by > some consensus of committers. We (Chromium) run into the same issues with > WebKit, which has had to ,,,team, but if such a patch is architecturally > clean and doesn't affect performance for clients that don't need it, it > ought to be accepted. > i honestly did look into the patching-submitting process almost a year ago, and found it, quite frankly, far too painful for me to invest the time in. i just wanted to submit documentation patches (i write very good technical docs, if i may say so myself), but the overhead of doing so is downright painful for someone not in the Chromium team. > Hm. It's usually considered a truism of garbage collection that finalizers > are not guaranteed to be called, and that resources that must be cleaned up > should be cleaned up manually. The Java VM specification, for example, > explicitly does not guarantee invocation of finalizers. > It's a truism that the destruction order is undefined, but not necessarily that they WON'T be cleaned up. > It is not necessary to close a FILE* explicitly when your process exits; > the OS will close the file handle for you. It might not flush it or do any higher-level operations which i've defined for my File-wrapper class to do at destruction. My canonical example here is the TempFile class, which deletes the local file at destruction. On Unix systems we can unlink() a file directly after opening without invalidating the handle, so this is not a problem on Unix. Windows, however, is not quite smart enough to allow that, so this workaround fails on those platforms, and on such platforms, the TempFile class will leave around garbage files after v8 exits. > You may need to flush the FILE* if it has unwritten buffered output, but > that is the kind of thing you should really be doing manually anyway: what > if you write a bunch of stuff without flushing, and then your process keeps > running for several days? That data hasn't been written to the file, so > anyone looking at the file will see partial data, and in the event of a > crash the file will be corrupt. > Agreed, but here the behaviour of v8 shutting down without running a GC (or giving me the opportunity to do so) is IN EFFECT the same as a crash. The objects destroyed this way will behave exactly as they do in the face of a crash. -- ----- stephan beal http://wanderinghorse.net/home/stephan/ -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
