What do you think about this setup for a highly concurrent server scenario.
To give the discussion some context, let us suppose that this server lets people browse a hierarchical filesystem. Let us also suppose that this server lets administrators setup javascript to calculate properties on-demand, so as users click on files or directories, in addition to the normal properties they also see the output of each configured javascript property.
b) The V8Runtime may eventually end up with a lot of junk old scripts presumably, but assuming the scripts don't change very often that shouldn't be significant. Is it possible to eventually allow the compiled script to be collected if nothing has a reference to it anymore?
c) The scripts themselves are created by trusted administrators, so if they want to junk up the environment by smashing all the prototypes and replacing Math with an object that always vends NaNs then that's their fault :) Presumably if we needed a higher safety mode we could dump the V8ScriptEngine and create a new instance, correct?
d) A big question is whether the compiled script can be re-used among V8ScriptEngine instances simultaneously, or if there are thread issues or locks involved. Could someone mutate the compiled script and introduce threading issues?
e) Another question relates to resource usage... are the limits enforced on the entire runtime or on each V8ScriptEngine instance?
f) Under what scenario would you even want multiple V8Runtime instances?
All opinions welcome! I think it would be awesome (and cut down on questions) to have some scenarios like this laid out and on the documentation page here on the site; then people could choose a design that matches their goals.
To give the discussion some context, let us suppose that this server lets people browse a hierarchical filesystem. Let us also suppose that this server lets administrators setup javascript to calculate properties on-demand, so as users click on files or directories, in addition to the normal properties they also see the output of each configured javascript property.
- One V8Runtime instance
- Each script is compiled and stored in an immutable hashtable. If the script associated to a property is modified, then a new script is compiled and a new mutated hashtable is installed with Interlocked.CompareExchange. The next request to come in will thus see the new list of script definitions to choose from.
-
When a request comes in on a worker thread that has no existing V8ScriptEngine instance assigned, a new instance will be created from the V8Runtime.CreateScriptEngine method. The script to be executed is located in the hashtable and executed. The V8ScriptEngine instance will be kept around, associated to that thread.
b) The V8Runtime may eventually end up with a lot of junk old scripts presumably, but assuming the scripts don't change very often that shouldn't be significant. Is it possible to eventually allow the compiled script to be collected if nothing has a reference to it anymore?
c) The scripts themselves are created by trusted administrators, so if they want to junk up the environment by smashing all the prototypes and replacing Math with an object that always vends NaNs then that's their fault :) Presumably if we needed a higher safety mode we could dump the V8ScriptEngine and create a new instance, correct?
d) A big question is whether the compiled script can be re-used among V8ScriptEngine instances simultaneously, or if there are thread issues or locks involved. Could someone mutate the compiled script and introduce threading issues?
e) Another question relates to resource usage... are the limits enforced on the entire runtime or on each V8ScriptEngine instance?
f) Under what scenario would you even want multiple V8Runtime instances?
All opinions welcome! I think it would be awesome (and cut down on questions) to have some scenarios like this laid out and on the documentation page here on the site; then people could choose a design that matches their goals.
