Subj : Re: JS_AddNamedRoot() and finalizer
To   : Matthew Mondor
From : Brendan Eich
Date : Thu Aug 26 2004 03:34 pm

Matthew Mondor wrote:

> This is why it is also important for me to be
> able to efficently "reset and recycle" the previous context so that it
> may be reused without needing to be re-created if possible, and
> without allowing a previous script to pollute the context of the next
> one to execute...


That's easily done if you JS_SetGlobalObject or JS_InitStandardClasses 
anew (you might prefer to use lazy standard class resolution instead of 
the latter API, see JS_ResolveStandardClass and 
JS_EnumerateStandardClasses; in that case, you'll just JS_SetGlobalObject).

If you use JS_SetContextPrivate and JS_GetContextPrivate, you'll need to 
reset the context's private data too.


> In this case, probably that as long as methods and properties which
> shared resource among multiple processes ensure to use proper
> synchronization, and keeping those shared resources opaque to
> SpiderMonkey, that it will be safe?


SpiderMonkey is safe in one process from any other process, or your OS 
is broken, or your interprocess communication used by your native hooks 
is buggy ;-).


> Perhaps that this is where adding
> root for some custom-allocated objects not tied to the SM context
> objects might become handy also...


Only if the context might go away.  But it sounds like it won't.  Its 
globalObject member will be reset between "sessions", and that will 
leave its previous value likely garbage to be collected, which sounds 
like what you want.


> But as long as I can have a user
> pointer to data tied to a JSObject (and this seems possible using the
> API) I should be able to work out the refcount and synchronization in
> the methods/properties which need some shared resources without
> allocating additionnal JS objects for it internally, that memory has
> to be shared anyways and thus allocated from a shared memory pool
> rather than using the process heap...


This could get costly to synchronize between processes.  Have you 
considered looser coupling than shared memory?  Just curious, not a 
SpiderMonkey question (I'm nosy ;-).


> BTW, I started writing some SpiderMonkey documentation (latex book
> format, although quite summary for now still, and mostly made for my
> own use, I might perhaps publish it under an open documentation
> license later on, and try to fill in the gaps I found when reading the
> various tutorials and examples I could find via the mozilla site
> links)...


Cool, thanks -- keep us apprised.  This might be perfect for the 
about-to-launch DevMo (http://developer.mozilla.org/) doc site.

/be

.