Objekt zwischen 2 Prozessen teilen.



  • Hallo!
    Ich habe mal wieder ein komplizierteres Problem.
    Ich programmiere gerade an einer größeren Applikation.
    Diese Applikation besitzt ein Hauptsystem, welches Shared Libraries nachladen kann, welche dann die eigendlichen Aktionen ausführen.

    So weit so gut, jetzt aber das große Problem:
    Ich möchte nicht, dass die Libraries mein Hauptprogramm beeinflussen können, außer über die vorgegebenen Schnittstellen. Also dass zum Beispiel, wenn ein Fehler in einer Library ist, nur der Teil mit der Library abstürzt, nicht aber das Hauptsystem.

    Dazu hab ich mir jetzt folgendes gedacht: Das Hauptsystem erstellt einen neuen Prozess (Prozess, nicht Thread), in dem quasi nur ein Loaderprogramm läuft, welches eine Klasse mit Schnittstellen für die Library enthällt und die Shared Library lädt.

    So weit zu der Idee. So weit würde Ich auch noch kommen, aber das große Problem ist jetzt, dass die Klasse in dem Loaderprogramm für die Library einen Pointer enthällt, hinter dem ein Objekt sitzt, welches aber Bestandteil des Hauptprogrammes ist und daher nicht so einfach für den neuen Prozess verfügbar ist.

    Gibt es da eine Möglichgkeit, dass auf dieses Objekt über die Prozessgrenzen zugegriffen werden kann und wenn ja, welche?

    Danke schon mal im Voraus.

    MfG
    FloFri



  • Ja, mit CORBA geht sowas. Mit Mico gibts da auch eine kostenlose Implementierung, falls Geld ne Rolle spielt. CORBA ist ja dafür gedacht, entfernte Objekte zu behandeln. Ob die Objekte auf zwei verschiedenen physikalischen oder dem selben Rechner liegen, ist ja unerheblich.

    Wenn es MS-Technik sein darf, dann nimm DCOM oder am einfachsten ActiveX (ist in VisualC++ schnell ein Adapter für deine Klassen zusammen gebaut).

    Eine Einfache Lösung, wo du aber eher keine Objekte aber Daten austauschen kannst, ist Sharedmemory. Von Boost gibts da Shmem, welches auch Platformübergreifend funktioniert.



  • So weit so gut, jetzt aber das große Problem:
    Ich möchte nicht, dass die Libraries mein Hauptprogramm beeinflussen können, außer über die vorgegebenen Schnittstellen. Also dass zum Beispiel, wenn ein Fehler in einer Library ist, nur der Teil mit der Library abstürzt, nicht aber das Hauptsystem.

    Aber doch nicht durch die Verwendung mehrerer Prozesse.

    Um die Libaries dazuzuzwingen nicht direkt auf das Hauptprogramm zuzugreifen, sondern die Schnittstelle zu benutzen dürfte wesentlich einfacher dadurch zu realisieren sein, dass nur die Header-Dateien der Schnittstelle den Bibliotheken zur Verfügung gestellt werden.

    Das mit dem Abstürzen würde ich eher über eine robuste Schnittstellen-Definition und dem Einsatz von try/catch-Blöcken lösen.

    Das Aufsplitten in mehrere Prozesse macht an der Stelle dein System langsamer und instablier. Denn die Kommunikation zwischen den Prozessen frißt Zeit, vorallem dann wenn sie nur nacheinander arbeiten können und reger Datenaustausch nötig ist.
    Außerdem entstehen neue Fehlerquellen wie zum Beispiel Deadlocks....



  • Würde mich ein Try/Catch auch vor division by zero oder null pointer dereferenzierungen schützen? Das ist nähmlich das, was mir am meisten kopfzerbrechen bereitet, dass so ein programmierfehler dann das ganze hauptsystem weghaut.

    Mit den deadlocks oder synchronisierungen mache ich mir da keine sorgen, da die Libraries auch jetzt schon in eigenen Threads unabhängig von einander laufen.



  • Mathias schrieb:

    So weit so gut, jetzt aber das große Problem:
    Ich möchte nicht, dass die Libraries mein Hauptprogramm beeinflussen können, außer über die vorgegebenen Schnittstellen. Also dass zum Beispiel, wenn ein Fehler in einer Library ist, nur der Teil mit der Library abstürzt, nicht aber das Hauptsystem.

    Aber doch nicht durch die Verwendung mehrerer Prozesse.

    Um die Libaries dazuzuzwingen nicht direkt auf das Hauptprogramm zuzugreifen, sondern die Schnittstelle zu benutzen dürfte wesentlich einfacher dadurch zu realisieren sein, dass nur die Header-Dateien der Schnittstelle den Bibliotheken zur Verfügung gestellt werden.

    das ändert aber nichts daran, das eine Bibliothek sich schadhaft verhalten kann. Zum Beispiel könnte der Code fehlerhaft sein und Segfaults auslösen oder ähnliches.

    Das mit dem Abstürzen würde ich eher über eine robuste Schnittstellen-Definition und dem Einsatz von try/catch-Blöcken lösen.

    Schnittstellen haben damit doch nichts zu tun und try/catch hilft nur bei C++-Exceptions, nicht bei Systemfehlern.

    Das Aufsplitten in mehrere Prozesse macht an der Stelle dein System langsamer und instablier. Denn die Kommunikation zwischen den Prozessen frißt Zeit, vorallem dann wenn sie nur nacheinander arbeiten können und reger Datenaustausch nötig ist.
    Außerdem entstehen neue Fehlerquellen wie zum Beispiel Deadlocks....

    Das System wird doch nicht instabiler. Der Datenaustausch ist natürlich langsamer, aber vermutlich eher unwesentlich, da Shared-Memory afaik keinen Overhead hat.

    @FloFri
    du musst dir eben nur bewusst sein, das du nicht alle Möglichkeiten von schadhaften verhalten ausschließt. Jemand kann dir zB relativ leicht falsche Daten liefern (zB im Sinne von zerschossenen Objekten). Aber das ist eben die Frage, wie viel Sicherheit du haben willst und wie weit du dafür bereit bist Geschwindigkeit zu verlieren.



  • Ich werde es mal mit einem Shared Memory probieren, der von Boost sieht vielversprechend aus, danke für die Antworten.


Anmelden zum Antworten