SubProcess.pm Datenverlust ?

[Dr. Boris Neubert]

Hallo Dirk,

habe es mit kleinen Korrekturen eingecheckt.

Viele Grüße
Boris

[zap]

Neuigkeiten zu SubProcess.pm:

Inzwischen verwende ich SubProcess.pm in HMCCU, um RPC-Server Prozesse zu starten. Für die Kommunikation zwischen Child- und Parent-Prozess setze ich aber nach wie vor auf File-Queues. Die direkte Kommunikation zwischen Child und Parent über Sockets funktioniert nur bis zu einem gewissen Datenaufkommen. Wird in kurzer Zeit eine große Menge Daten von einem Child- zum Parent-Prozess geschickt, schlagen irgendwann die Write-Calls fehl. Das Problem lässt sich durch Erhöhung der Timeouts etwas verzögern, jedoch nicht vermeiden. m.E. kommt ab einem bestimmten Punkt FHEM nicht mehr mit der Verarbeitung der Daten und die Übergabe an die Read-Funktion nach. Ab einem Punkt läuft dann irgendein I/O Puffer voll und weitere Daten werden ins Nirwana geschickt (so ca. ab 5 Kb auf meinem Raspi, auf schnelleren Systemen vielleicht anderer Wert).

Schade eigentlich. Sonst funktioniert SubProcess.pm einwandfrei. Habe jetzt 2 Tage lang versucht, das zum laufen zu bekommen. Letztendlich muss ich wohl akzeptieren, dass Perl für solche zeitkritischen Dinge auf schwachbrüstigen Systemen nicht geeignet ist.

Ach ja: Für die Funktion running() werde ich noch einen Patch liefern. Die arbeitet so nicht zuverlässig. Für die Prüfung, ob ein Prozess läuft, ist kill mit dem Signal 0 besser geeignet.