noch eine idee zu blocking/fork/timing & co

[ntruchsess]

Hallo Andre,

Ich hab ja auch vor ein paar Monaten so einen ähnlichen Ansatz implementiert, aber mangels Zeit nie zur Einsatzreife gebracht, hätte auch mehr Anpassungen an den eigentlichen Devicemodulen benötigt.
Deinen Ansatz finde ich wirklich super, weil weitestgehend rückwärtskompatibel zum bestehenden code!
Die Kommunikation zwischen Haupt-prozess und Sandboxen könnte man in einem Queue-interface kapseln, dann könnte man das gleiche Prinzip auch mit Perl-threads nutzten, oder über Unix-pipes kommunizieren und so eventuell Resourcen sparen.

Gruß,

Norbert

[justme1968]

ja. der eigentliche schwachpunkt ist noch die kommunikation. die idee ist diese mehr zu kapseln und dann neben den kommandos auch serialisierte datenstrukturen zur senden und zu dispatchen. dann hätte man auf der nächsten stufe gleich ein api um nicht nur zu kapseln sondern auch explizit zu kommunizieren.

an diese kommunikation muss dann auch noch eine 'totmannschaltung' um eine sandbox neu zu starten bevor es einen deadlock auf den sockets gibt.

wenn man das ganze dann so erweitert das neben den lokalen sockets auch andere wege möglich sind lässt sich das auch noch auf andere anwendungsfälle erweitern. im prinzip ist es dann auch nicht mehr auf einen einzelnen rechner beschränkt sondern könnte in richtung fhem cluster/failover werter entwickelt werden. aber das ist Zukunftsmusik.

ich hoffe das gerade die möglichkeit ein oder mehrere unveränderte module in die sandbox zu stecken für genug interesse sorgt das tatsächlich bis zur einsatzreife reicht. ich möchte es auf jeden fall für zumindest für OWServer/OWDevice produktiv benutzen.

gruss
  andre