Hosting IronRuby/DLR in long running applications

Following up on this discussion on ASP.NET:

We are considering hosting IronRuby in our application (ASP.NET
website & a couple windows services). I am looking for any guidance
around which objects should be cached, and what should be created on
the fly. The responses from the previous thread seemed to suggest it
is safe to cache the ScriptEngine. I’m wondering where else I might
want to cache, and where I would NOT want to cache (if an object is
not thread safe, and shouldn’t be used to fulfill multiple
simultaneous requests).

Specifically, we are using IronRuby to provide some customization to
the application. For (simplified) example, suppose we wanted to
provide the ability to customize a greeting. I want to store the
script that generates the greeting in the web.config (either the
script itself, or the path to the script).

My theory is that I can create a CompiledCode instance during
application startup, and then execute the compiled code with different
scopes for each request (to provide request-specific data). Is this
the proper/recommended way of executing the same script with different
data within an application? Is it safe to called CompiledCode.Execute
from multiple threads simultaneously?

Sample code that shows what I plan to do:

// Perform all these steps in global.asax application_start
var scriptFromConfigFile = @“”“Hi #{ctx.first_name}
#{ctx.last_name}”“”; // read from web.config appSettings
var scriptEngine = IronRuby.Ruby.CreateEngine();
//GreetingScript is cached as a singleton so that it is available to
var GreetingScript =

// during each individual web request, change the context object
passed to the script
var scriptScope = GreetingScript.Engine.CreateScope();
scriptScope.SetVariable(“ctx”, new {FirstName=“John”, LastName=“Doe”});
var greeting = GreetingScript.Execute(scriptScope);


Your theory is all right. It is CompiledCode’s purpose to be executed
many times against different scopes. CompiledCode.Execute is thread-safe
provided that the script being executed and the scope storage are. The
data-structures IronRuby and DLR use internally are thread-safe. If you
use ScriptScope with default storage (you do so in the sample below) and
if the script doesn’t modify shared state not protected by a lock than
everything should work just fine.