Remoting - running a rekenhart in another process

Intro

DeltaShell provides an implementation to run services remote (in another process / on another machine). The most common usage is to load and the calculation kernel (typically fortran) of a model in a separate process to increase DeltaShell stability and prevent memory corruption issues when running a model several times.

Typically when you are making a model (wrapper) in DeltaShell and you work with an external / native dll you should define a C# interface and a C# implementation of that interface (which in turn typically calls methods in a native dll), for example:

// model interface
public interface IMyModelApi
{
   void Initialize();
   void DoTimeStep();
   double GetValue(int location);
   void SetValue(int location, double value);
}

// implementation
public class MyModelApi : IMyModelApi
{
   public void Initialize() {/*implementation*/}
   public void DoTimeStep() {/*implementation*/}
   public double GetValue(int location)
   {
      // typically interaction with native dll
   }

   void SetValue(int location, double value)
   {
      // typically interaction with native dll
   }
}

You would normally create an instance of the implementation like this to use in your model wrapper:

IMyModelApi api = new MyModelApi();

// usage:
public void Initialize
{
  api.SetValue(pumpId, 5.0); //set initial value
  api.Initialize();
}

One of the disadvantages of this approach is that if a native dll is loaded using DllImport, it will never be unloaded until the process (DeltaShell) exists. As a consequence, any memory leaks in the native dll will build up in the parent process, omissions in re-initialization may cause model corruption, or in general: previous runs may affect the current run. Most notably, when the dlls aborts / causes an access violation, it will instantly crash the entire parent process (eg DeltaShell) without chance of recovery.

What is typically done to work around these issues, is that for each model-run a new 'worker' process is spawned. That worker process then loads the native dll, does the model calculations and then exits. For subsequent runs a new process is launched, thus making sure each run is 'clean'. To allow for interaction during the run, the DeltaShell process and the worker process need to communicate, which is called 'remoting'. The worker process may run on the local machine, but could also run on another machine.

Solution

To hide all the complexities of remoting, Delta Shell provides a few simple methods to work with a 'remote' version of your api. Typically you will have to change very little in your model code if you already have a well defined interface for your api.

So if you previously did this:

IMyModelApi api = new MyModelApi();
api.Initialize();

You can now do this:

IMyModelApi api = RemoteInstanceContainer.CreateInstance<IMyModelApi, MyModelApi>();
api.Initialize();

And you can now use the 'api' variable just like before, but behind the scenes DeltaShell has started a new process and each call you make to the api is in fact intercepted and delegated to the worker process.

There is one extra step you have to take to clean things up:

RemoteInstanceContainer.RemoveInstance(api);

This will tell DeltaShell to end the worker process and cleanup any resources. After this the api variable is no longer usable. Next run you should call CreateInstance again.

Requirements on the interface

Performance considerations