Obsługa wielu wystąpień biblioteki DLL wtyczki z danymi globalnymi

Question

Kontekst: Przekształciłem starszy autonomiczny silnik w komponent wtyczki dla narzędzia kompozycji. Z technicznego punktu widzenia oznacza to, że skompilowałem bazę kodu silnika do biblioteki DLL C, którą wywołuję z opakowania .NET za pomocą P/Invoke; wrapper implementuje interfejs zdefiniowany przez narzędzie do komponowania. Działa to całkiem dobrze, ale teraz otrzymuję żądanie załadowania wielu instancji silnika dla różnych projektów. Ponieważ silnik przechowuje dane projektu w zbiorze zmiennych globalnych, a ponieważ biblioteka DLL z podstawą kodu silnika jest ładowana tylko raz, ładowanie wielu projektów oznacza, że ​​dane projektu są nadpisywane.

widzę szereg rozwiązań, ale wszystkie one mają pewne wady:

1. Można utworzyć wiele bibliotek DLL z tego samego kodu, które są postrzegane jako różne biblioteki DLL w systemie Windows, więc ich kod nie jest udostępniony. Prawdopodobnie działa to, jeśli masz wiele kopii DLL silnika o różnych nazwach. Jednak silnik jest wywoływany z opakowania przy użyciu atrybutów DllImport i myślę, że nazwa silnika DLL musi być znana podczas kompilowania opakowania. Oczywiście, jeśli muszę skompilować różne wersje opakowania dla każdego projektu, jest to dość kłopotliwe.

2. Silnik może działać jako oddzielny proces. Oznacza to, że owijka uruchomiłaby oddzielny proces dla silnika podczas ładowania projektu i użyłaby jakiejś formy IPC do komunikacji z tym procesem. Chociaż jest to stosunkowo czyste rozwiązanie, to wymaga trochę wysiłku, aby uzyskać pracę, nie wiem, która technologia IPC byłaby najlepsza do stworzenia tego rodzaju konstrukcji. Może również występować znaczny narzut komunikacji: silnik musi często wymieniać tablice liczb zmiennoprzecinkowych.

3. Silnik można dostosować do obsługi wielu projektów. Oznacza to, że zmienne globalne powinny zostać umieszczone w strukturze projektu, a każde odniesienie do globali powinno zostać przekonwertowane na odpowiadające odniesienie, które odnosi się do konkretnego projektu. Istnieje około 20-30 zmiennych globalnych, ale jak można sobie wyobrazić, te zmienne globalne są przywoływane z całej bazy kodu, więc ta konwersja musiałaby zostać wykonana w sposób automatyczny. Powiązanym problemem jest to, że powinieneś być w stanie odnieść się do "aktualnej" struktury projektu we wszystkich miejscach, ale przekazanie tego jako dodatkowego argumentu w każdym podpisie funkcji jest również uciążliwe. Czy istnieje technika (w języku C) do rozważenia bieżącego stosu wywołań i znalezienia najbliższej instancji zawierającej odpowiednią wartość danych?

Czy społeczność stackoverflow może udzielić porady na temat tych (lub innych) rozwiązań?

Answer 1

Mimo, że otrzymał wiele odpowiedzi, które sugerowane iść do sporządzania roztworu 3, chociaż zgadzam się, że jest to lepsze rozwiązanie koncepcyjnie, myślę, że nie było sposobu, aby uświadomić sobie, że rozwiązanie praktycznie i niezawodnie pod moimi ograniczeniami.

Zamiast tego, co faktycznie zaimplementowałem, było odmianą rozwiązania nr 1. Chociaż nazwa biblioteki DLL w DLLImport musi być stała czasu kompilacji, this question wyjaśnia, jak to zrobić dynamicznie.

Jeśli mój kod przed wyglądał następująco:

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 
    } 
} 

ona teraz wygląda tak:

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 
    } 

} 

Uff.

Może to wydawać się bardzo skomplikowane, jeśli zobaczysz dwie wersje obok siebie, ale po skonfigurowaniu infrastruktury jest to bardzo systematyczne zmiany. Co ważniejsze, lokalizuje modyfikację mojej warstwy DotNetAccess, co oznacza, że ​​nie muszę wykonywać modyfikacji rozproszonych po bardzo dużej podstawie kodu, która nie należy do mnie.

Answer 2

Moim zdaniem, rozwiązanie 3 jest drogą do zrobienia.

Wada polegająca na tym, że musisz dotknąć każdego połączenia z biblioteką DLL, powinna również odnosić się do innych rozwiązań ... bez braku skalowalności i nieprzyjemności podejścia opartego na wielu bibliotekach DLL i niepotrzebnego obciążenia IPC.

Answer 3

Umieścić całą rzeczą cry w klasie C++, a odwołania do zmiennych automatycznie znajdą zmienną instancji.

Możesz wykonać globalny wskaźnik do aktywnej instancji. Prawdopodobnie powinien to być lokalny wątek (patrz __declspec(thread)).

Dodaj extern "C" funkcje opakowania, które przekazują do odpowiedniej funkcji elementu na aktywnej instancji. Udostępnia funkcje do tworzenia nowej instancji, usuwania istniejącej instancji i ustawiania aktywnej instancji.

OpenGL używa tego paradygmatu do świetnego efektu (patrz wglMakeCurrent), znajdując jego dane stanu bez konieczności przekazywania wskaźnika stanu do każdej funkcji.

Answer 4

Rozwiązanie 3 To jest właściwa droga.

Wyobraź sobie, że obecne języki programowania obiektowego działają podobnie do trzeciego rozwiązania, ale tylko pośrednio przekazują wskaźnik do struktury zawierającej dane "to".

Przekazywanie "czegoś w rodzaju kontekstu" nie jest kłopotliwe, ale tak właśnie działa! ;-)

Answer 5

W rzeczywistości rozwiązanie 3 jest łatwiejsze niż się wydaje. Wszystkie inne rozwiązania są rodzajem poprawki i z czasem zerwą.

• Utwórz klasę .net, która będzie hermetyzować dostęp do dotychczasowego kodu. Spraw, aby był możliwy do zidentyfikowania.
• Zmień wszystkie zmienne globalne, aby rezydowały w klasie o nazwie "Kontekst"
• Niech wszystkie interfejsy C++ pobierają obiekt kontekstu i przekazują go jako pierwszy argument. Jest to prawdopodobnie najdłuższy etap i możesz tego uniknąć używając metody "thread-local-storage" sugerowanej przez kogoś innego, ale głosowałbym przeciwko temu rozwiązaniu: jeśli twoja biblioteka ma działające wątki, które uruchamia, "wątek-lokalny" "rozwiązanie" zostanie przerwane. Wystarczy dodać obiekt kontekstu tam, gdzie jest potrzebny.
• Użyj obiektu kontekstowego, aby uzyskać dostęp do wszystkich danych globalnych.
• Utworzono obiekt kontekstu z .net ctor (przez p/wywołanie nowej funkcji create_context) i usunięto go przy użyciu metody .net Dispose().

Ciesz się.

Answer 6

Użyj podejścia nr 3. Ponieważ kod znajduje się w C, łatwym sposobem radzenia sobie z rozproszonymi wszędzie globami jest zdefiniowanie makra dla każdego globalnego, który ma taką samą nazwę jak zmienna globalna, ale makro rozwija się do czegoś takiego jak getSession() -> theGlobal gdzie getSession() zwraca pinter do struktury "specyficznej dla sesji", która przechowuje wszystkie dane dla twoich globali. getSession() może w jakiś sposób łowić odpowiednią strukturę danych z globalnej mapy struktur danych, być może przy użyciu lokalnego magazynu wątków lub na podstawie identyfikatora procesu itp.

Answer 7

Kilka uwag na temat sugerowanego rozwiązania # 2 (i trochę na temat Nr 1 i nr 3).

1. Pewna warstwa IPC może wprowadzić opóźnienie. To zależy od rzeczywistego silnika, jaki jest zły. Jeśli silnik jest silnikiem renderującym i jest wywoływany, powiedzmy, 60 razy na sekundę, obciążenie może być zbyt duże. Ale jeśli nie, nazwany potok może być wystarczająco szybki i łatwy do utworzenia za pomocą WCF.
2. Czy jesteś całkowicie pewien, że będziesz potrzebował DOKŁADNIE tego samego silnika wiele razy lub czy istnieje ryzyko zmiany wymagań, które mogą prowadzić do scenariusza, który zmusza do ładowania wielu wersji jednocześnie? Jeśli tak, opcja nr 2 może być lepszym rozwiązaniem niż opcja nr 3, ponieważ pozwoliłoby to na łatwiejsze.
3. Jeśli warstwa IPC nie spowalnia rzeczy zbyt mocno, architektura ta może pozwolić na dystrybucję silników na innych komputerach. Może to umożliwić użycie większego sprzętu, niż wcześniej zaplanowano. Można nawet myśleć o hostowaniu silnika w chmurze Azure.