HMCCURPC - Inkompatibilität mit HUEBridge (JSON)

[herrmannj]

JSON::XS ist nicht thread safe !

Explizit JSON::PP verwenden löst das Problem.
JSON::XS erst laden _nachdem_ der thread gestartet ist reicht auch (ist aber praktisch nicht umsetzbar)

Threads aus dem fhem Hauptprozess heraus starten ist aber ohnehin eine Sünde da (perl) threads eine _komplette_ Kopie des Speichers erzeugen. Da wird komplett alles kopiert, ohne copy on write.

allow_non_ref ist ein Symptom, nicht die Ursache.

[zap]

JSON::XS ist nicht thread safe !

Explizit JSON::PP verwenden löst das Problem.
JSON::XS erst laden _nachdem_ der thread gestartet ist reicht auch (ist aber praktisch nicht umsetzbar)

Threads aus dem fhem Hauptprozess heraus starten ist aber ohnehin eine Sünde da (perl) threads eine _komplette_ Kopie des Speichers erzeugen. Da wird komplett alles kopiert, ohne copy on write.

allow_non_ref ist ein Symptom, nicht die Ursache.

Unterschreibe ich Dir alles. Die möglichen Lösungen sind alles Workarounds.

Ursache ist für mich die Art und Weise, wie in den letzten Jahren bei Perl alle neueren Features "dran gefrickelt" wurden. Ob das Threads sind oder eben die Beschleunigung XS für JSON. Viele Perl Module sind irgendwo bei Version 0.x stehen geblieben und werden nicht mehr weiter entwickelt. Deshalb habe ich auch keine Hoffnung, dass die Threads/JSON::XS Problematik gelöst wird. Es besteht einfach kein Bedarf dafür. Alle neuen Sachen werden in Python, Nodejs oder ... entwickelt.

Das Starten der Threads aus einem Subprozess hatte ich schon mal. Aber dann macht eben FHEM die Grätsche, wenn die CCU bei der Initialisierung Massen von Daten schickt. Hatte ich aber schon mal beschrieben. Puffern würde zwar gehen, allerdings verzögert das die Initialisierung der Schnittstelle ins Endlose.

Nur wieso ist allow_nonref ein Symptom? Es gibt den alten JSON Standard (RFC 4627) und den neuen (RFC 7159). Und der neue besagt eben "Due to security concerns, JSON::XS will not allow scalar data in JSON texts by default - you need to create your own JSON::XS object and enable allow_nonref". Ist halt so, kann man akzeptieren, ignorieren oder was auch immer. In der Doku steht zwar, dass man Strings übergeben kann, aber das bezieht sich eben auf den alten Standard. Und mit Debian Stretch wurde nun anscheinend etwas geändert, denn vor dem Update auf Stretch ist der Fehler nicht aufgetreten.

[zap]

Mit der neuen HMCCU Version sollte das Thema erledigt sein:

https://forum.fhem.de/index.php/topic,83544.0.html

HMCCURPC mit Threads war zwar irgendwie eleganter, aber HMCCURPCPROC nutzt nun fork() statt Threads und hat daher kein Problem mit JSON::XS.

Memory-Verbrauch ist wie bei Threads. Performance auch. Ich musste nur ein paar Klimmzüge machen, wenn der I/O Loop in FHEM die Events der CCU nicht schnell genug verarbeiten kann. Dann wird halt eine Queue bemüht und es kommt zu einer Verzögerung von bis zu 1 Sekunde.

Also liebe Thread/JSON::XS Geplagte: Morgen Updaten und umstellen auf HMCCURPCPROC.