Subj : Re: 'Replacing' loaded functions and host objects in a shared scope To : Eric Merritt From : Igor Bukanov Date : Fri Aug 22 2003 09:59 am Eric Merritt wrote: > Hello all, > > I am trying to embed rhino in a servlet application. So far > everything works well, but I think that there is a more efficient way > to do things then the way I currently am doing them. > > Right now I have three types of things that get put into two scopes, > a lib scope and a script scope. The lib scope holds library type > functions and host objects, the script scope holds individual functins > that may be called. The lib scope serves as a prototype to the script > scope. Lib scripts, Script scripts and host objects may be changed on > the fly and need to be reloaded. For the script scope things are easy, > if the script changes on disk I just create a new scope, set the lib > scope as its prototype and evaluate the script (I actually call the > script functions later). The lib scope is where I am worried. > Currently if a host object or script changes I discard the parent > scope reload all of the lib scripts and host objects to get them into > the new scope, then I reload all of the scripts in the script scope. > This is ok now becuase there are not to may of the lib scripts or host > objects. However, that will change. > > Remembering that this is a multi-threaded environment what are the > implications of simply re-evaluating the lib scripts in the original > lib scope and if a host object changes simply re-inserting the host > object with the same name in the lib scope. It depends on the scripts. If they declare scope variables without assigning a value, then when you re-evaluate the script, the variables will keep the old values. And any read-only property in the scope will keep the old value as well. Another problem is that if the new version does not define a particular function, then the old function will still present in the scope consuming memory. That can be very significant since the function contains references to many objects including the old value of Function.prototype which will keep a significant amount of the standard library objects in memory. Old scope reuse would not bring any speedups either since parsing/generation of code for scripts will consume probably 100 times more time compared with creation of new properties in the scope. > I worry that this is going > to have syncronazation issues becuase scripts in the script scope rely > on the lib scope. Will this work for the lib scope? If I can do this > with the lib scope can I reuse script scopes in a similar way? The protection against 2 threads re-initializing the scope with new versions of scripts is hard to achieve. Rhino contains a hash table implementation that is synchronization-free when you read a property so even if the scope re-initialization is done under synchronized (scope), it would not prevent another thread from accessing scope properties in the middle of re-initialization. Regards, Igor .