Subj : Re: Narrowed the problem down to... To : Sterling Bates From : Brendan Eich Date : Thu Nov 06 2003 10:07 am Sterling Bates wrote: >"Brendan Eich" wrote in message >news:3FA85E39.30102@meer.net... > > >>That's not good design in general (not saying your particular solution >>is bad): object is to thread (context) as fish is to bicycle. An object >>might track which runtime contained it in the runtime's GC heap. But >>context makes no sense, unless you're very sure you will always have >>only one context per runtime. >> >> > >What I understand you saying is that I can create an object independent of >any context (cx == nil?), > No, you can't use null for the cx parameter, but yes: you create an object independent of any context (unless your constructor insists on making some private data in the object depend on the cx on which it was created, which is the general design flaw I cite). > and any script running within the runtime can >access the created object. When I execute JS_Finish(FRuntime), that's when >the object is freed up. > > Actually, sooner: the GC finalizes objects, so it may be freed soon after it becomes garbage, depending on whe you run the GC. And the "last GC" happens not from JS_DestroyRuntime (AKA JS_Finish), but from the last JS_DestroyContext. >I'll have to read more about the context & runtime objects to get a better >understanding of what they do. It was only today that I read the API doc >for JS_DefineObject, and saw that cx is passed in case an error is raised. >Is that the only reason? > > There are potentially other reasons, but they all have to do with execution state for the calling thread, which is what a cx hides. They have nothing to do with object lifetime or "scope". /be .