Supporting multiple instances of a plugin DLL with global data

Question

Context: I converted a legacy standalone engine into a plugin component for a composition tool. Technically, this means that I compiled the engine code base to a C DLL which I invoke from a .NET wrapper using P/Invoke; the wrapper implements an interface defined by the composition tool. This works quite well, but now I receive the request to load multiple instances of the engine, for different projects. Since the engine keeps the project data in a set of global variables, and since the DLL with the engine code base is loaded only once, loading multiple projects means that the project data is overwritten.

I can see a number of solutions, but they all have some disadvantages:

1. You can create multiple DLLs with the same code, which are seen as different DLLs by Windows, so their code is not shared. Probably this already works if you have multiple copies of the engine DLL with different names. However, the engine is invoked from the wrapper using DllImport attributes and I think the name of the engine DLL needs to be known when compiling the wrapper. Obviously, if I have to compile different versions of the wrapper for each project, this is quite cumbersome.

2. The engine could run as a separate process. This means that the wrapper would launch a separate process for the engine when it loads a project, and it would use some form of IPC to communicate with this process. While this is a relatively clean solution, it requires some effort to get working, I don't now which IPC technology would be best to set-up this kind of construction. There may also be a significant overhead of the communication: the engine needs to frequently exchange arrays of floating-point numbers.

3. The engine could be adapted to support multiple projects. This means that the global variables should be put into a project structure, and every reference to the globals should be converted to a corresponding reference that is relative to a particular project. There are about 20-30 global variables, but as you can imagine, these global variables are referenced from all over the code base, so this conversion would need to be done in some automatic manner. A related problem is that you should be able to reference the "current" project structure in all places, but passing this along as an extra argument in each and every function signature is also cumbersome. Does there exist a technique (in C) to consider the current call stack and find the nearest enclosing instance of a relevant data value there?

Can the stackoverflow community give some advice on these (or other) solutions?

Answer 1

Put the whole darn thing inside a C++ class, then references to variables will automatically find the instance variable.

You can make a global pointer to the active instance. This should probably be thread-local (see __declspec(thread)).

Add extern "C" wrapper functions that delegate to the corresponding member function on the active instance. Provide functions to create new instance, teardown existing instance, and set the active instance.

OpenGL uses this paradigm to great effect (see wglMakeCurrent), finding its state data without actually having to pass a state pointer to every function.

Answer 2

Although I received a lot of answers that suggested to go for solution 3, and although I agree it's a better solution conceptually, I think there was no way to realize that solution practically and reliably under my constraints.

Instead, what I actually implemented was a variation of solution #1. Although the DLL name in DLLImport needs to be a compile-time constant, this question explains how to do it dynamically.

If my code before looked like this:

using System.Runtime.InteropServices;

class DotNetAccess {
    [DllImport("mylib.dll", EntryPoint="GetVersion")]
    private static extern int _getVersion();

    public int GetVersion()
    {
        return _getVersion();
        //May include error handling
    }
}

It now looks like this:

using System.IO;
using System.ComponentModel;
using System.Runtime.InteropServices;
using Assembly = System.Reflection.Assembly;

class DotNetAccess: IDisposable {
    [DllImport("kernel32.dll", EntryPoint="LoadLibrary", SetLastError=true)]
    private static extern IntPtr _loadLibrary(string name);
    [DllImport("kernel32.dll", EntryPoint = "FreeLibrary", SetLastError = true)]
    private static extern bool _freeLibrary(IntPtr hModule);
    [DllImport("kernel32.dll", EntryPoint="GetProcAddress", CharSet=CharSet.Ansi, ExactSpelling=true, SetLastError=true)]
    private static extern IntPtr _getProcAddress(IntPtr hModule, string name);

    private static IntPtr LoadLibrary(string name)
    {
        IntPtr dllHandle = _loadLibrary(name);
        if (dllHandle == IntPtr.Zero)
            throw new Win32Exception();
        return dllHandle;
    }

    private static void FreeLibrary(IntPtr hModule)
    {
        if (!_freeLibrary(hModule))
            throw new Win32Exception();
    }

    private static D GetProcEntryDelegate<D>(IntPtr hModule, string name)
        where D: class
    {
        IntPtr addr = _getProcAddress(hModule, name);
        if (addr == IntPtr.Zero)
            throw new Win32Exception();
        return Marshal.GetDelegateForFunctionPointer(addr, typeof(D)) as D;
    }

    private string dllPath;
    private IntPtr dllHandle;

    public DotNetAccess()
    {
        string dllDir = Path.GetDirectoryName(Assembly.GetCallingAssembly().Location);
        string origDllPath = Path.Combine(dllDir, "mylib.dll");
        if (!File.Exists(origDllPath))
            throw new Exception("MyLib DLL not found");

        string myDllPath = Path.Combine(dllDir, String.Format("mylib-{0}.dll", GetHashCode()));
        File.Copy(origDllPath, myDllPath);
        dllPath = myDllPath;

        dllHandle = LoadLibrary(dllPath);
        _getVersion = GetProcEntryDelegate<_getVersionDelegate>(dllHandle, "GetVersion");
    }

    public void Dispose()
    {
        if (dllHandle != IntPtr.Zero)
        {
            FreeLibrary(dllHandle);
            dllHandle = IntPtr.Zero;
        }
        if (dllPath != null)
        {
            File.Delete(dllPath);
            dllPath = null;
        }
    }

    private delegate int _getVersionDelegate();
    private readonly _getVersionDelegate _getVersion;

    public int GetVersion()
    {
        return _getVersion();
        //May include error handling
    }

}

Phew.

This may seem extremely complex if you see the two versions next to each other, but once you've set up the infrastructure, it is a very systematic change. And more importantly, it localizes the modification in my DotNetAccess layer, which means that I don't have to do modifications scattered all over a very large code base that is not my own.

Answer 3

In my opinion, solution 3 is the way to go.

The disadvantage that you have to touch every call to the DLL should apply to the other solutions, too... without the lack of scalability and uglyness of the multiple-DLL approach and the unnecessary overhead of IPC.

Answer 4

Solution 3 IS the way to go.

Imagine, that current object oriented programming languages work similar to your 3rd solution, but only implicitly pass the pointer to the structure that contains the data of "this".

Passing around "some kind of context thing" is not cumbersome, but it is just how things work! ;-)