Subj : Re: [spidermonkey] JS_CallFunction in Finalize
To   : netscape.public.mozilla.jseng
From : Franck
Date : Sun Aug 28 2005 07:59 pm

Thanks for your help Brendan,

My current problem is that I'm just between these two cases :
 > It's up to the GC when to finalize.  It is up to you or your users' code 
when to "Close".


Currently I'm working on a wrapper to libffi ( a kind of JNI for 
javascript ).
The current state of my project allows me to do such things:

  function Alert( text, caption ) {

    var ret = new NativeData().PU32.Alloc(1);
    new NativeModule('C:\\WINDOWS\\SYSTEM32\\User32').Proc('MessageBoxA')( 
ret, DWORD( 0 ), SZ(text), SZ( caption || "Alert" ), DWORD( 1 ) );
    return ret[0];
  }

The 'Module' class is the one that manages the loaded dll/so file.
This class have a 'Close' method and a 'Finalize hook' that both release the 
dll/so handler ( if the handler is not released by the user, it is done when 
GC is called )


Later, I tried to use wxJS with my project. The order of the wxJS use is 
important:

  load wxJS library;
  JS_NewRuntime, JS_NewContext;
  wxJS_Init;
  JS_ExecuteScript;
  wxJS_Destroy;
  JS_DestroyContext, JS_DestroyRuntime;
  free wxJS library;

My first problem is that libraries like wxJS use the SpiderMonkey's API, so 
it is not possible to close them at a random ( GC ) time but only after the 
context is destroyed.

My second problem is that 'wxJS_Destroy' has to be called before the context 
is destroyed.

so the only way I found is a kind of 'onClose' property that has to be 
defined like this:

  function LoadWxJs() {

    var libWxJS = new NativeModule('...\\wxJS' );    // .dll/.so
    libWxJS.onClose = function() { libWxJS.Proc('wxJS_Destroy')( 
VOID() ); };
    var ret = new NativeData().PS32.Alloc(1);
    libWxJS.Proc('wxJS_Init')( ret, MAKEPTR( JSContextToPtr() ), MAKEPTR( 
JSObjectToPtr( this ) ) );
  }

My wish is that people that use LoadWxJs has not to care about any 
'wxJS_Destroy' ...




"Brendan Eich" <brendan@meer.net> a écrit dans le message de news: 
deo10o$h9a1@ripley.aoltw.net...
> Brendan Eich wrote:
>> Brendan Eich wrote:
>>
>>> Consider DOM window objects.  If I write <script> window.open("foo.com") 
>>> </script>, I shouldn't leak, but the opened window should be visually 
>>> closed when the user clicks on its close [x] box or whatever widget is 
>>> used by the desktop/window-manager/OS for closing windows, and at *that* 
>>> point, "onunload" or a hypothetical "onclose" event handler should 
>>> run -- *not* later when the window object is finalized by the GC.
>>
>>
>> Now consider
>>
>> <script>
>> var w = window.open("http://foo.com");
>> w.close();
>> alert(w.fooVar);
>> </script>
>
> This example was fake, it pretended that window.open is synchronous. 
> Here's a real example:
>
> /tmp/foo.html:
> <script>
> var w = window.open("file:///tmp/bar.html");
> alert(w);
> w.onload = function () {
>     w.close();
>     alert(w.barVar);
> };
> </script>
>
> /tmp/bar.html:
> <script>
> var barVar = "hello from bar.html!";
> </script>
>
> Once you've disabled the Firefox popup blocker appropriatly for file: (or 
> the empty host part, eek!), you should see a new window followed by two 
> alerts, the first showing "[object Window]", the second "hello from 
> bar.html!".
>
> /be

.