Blocking functions: BlockingCall, SubProcess, CoProcess, HttpUtils_NonblockingGe

Begonnen von KölnSolar, 08 Januar 2020, 10:22:17

Vorheriges Thema - Nächstes Thema

KölnSolar

Hallo Ihr Lieben,
immer wieder haben wir ja wegen den unterschiedlichsten Modulen Anfragen zu Latenzen/freezes. Ich hab das Gefühl(und es wird dank Cloud  >:( :'( immer mehr), dass von der wachsenden(das ist prima) Entwicklerzahl mehr Wert auf Funktion als Performance gelegt wird. Funktion heißt dabei oft lediglich: Informationen periodisch(internaltimer) aus "fremden" Datenquellen(files, Cloud, irgendwelche nodejs/python Anwendungen....) zu beschaffen. Ich bin der Auffassung, dass diese Informationsbeschaffung nichts im Hauptprozess von FHEM zu suchen hat, da dieser dadurch ausgebremst wird und die meines Erachtens primäre FHEM-Funktion der event-Steuerung und Schaltzentrale nicht mehr quasi realtime erfolgt. Mal mehr, mal weniger. :'(

Ich kümmere mich um eins dieser bösen Module. Ein Read eines files dauert leider ca. 1 Sek. und vermutlich lässt sich daran nichts ändern. In meiner Installation werden 27 Reads/min. ausgeführt. Das war natürlich unbefriedigend bzgl. Latenzen/freezes/performance. Also habe ich(unwissend zu möglichen Nebenwirkungen) BlockingCall eingesetzt. Grundsätzlich war das Ergebnis mehr als zufriedenstellend. Nebenwirkungen hatte ich auch keine. Nun lese ich aber immer wieder, dass BlockingCall den Hauptprozess im Speicher kopiert und es deshalb zu Problemen kommen kann. Andre hat SubProcess und CoProcess als Alternative in den Raum gestellt, die zumindest die Speicherproblematik etwas mehr eingrenzen sollten. Viel findet man zu diesen Funktionen nicht und eine Test-Implementierung scheint mir auch nicht auf die Schnelle machbar.

Nun meine Fragen/Diskussionspunkte:
1. Wer weiß etwas mehr über die genannten Funktionen und kann Infos über Einsatzzweck, Nebenwirkungen, Beispiele, Unterschiede sagen/verlinken ?
2. Seht Ihr es nicht auch so, dass die periodisch pullenden Informationsbeschaffer-Funktionen GRUNDSÄTZLICH ausgelagert gehören und dass wir dazu einen "Entwicklungsleitfaden" haben sollten ?
(3. Ich beobachte erstmalig meinen Speicherverbrauch. FHEM: 340MB(seit 27 Tg.), alexa: 160MB, npm: 127MB, Python: 226MB, 83MB pi-hole.
     Ich erkenne da jetzt nicht das Problem, das gg. BlockingCall spricht. Eher gg. alexa,npm,Python...[bei einer komplexen Anwendung wie alexa oder zigbeemqtt ist mir die Notwendigkeit sehr wohl bewusst;Bei Kleinigkeiten frage ich mich aber immer, warum nicht versucht wird externe open-source in Perl zu übersetzen])


Danke&Grüße
Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Dr. Boris Neubert

Hallo,

zu SubProcess gibt es in contrib eine Beispielimplementierung.

Viele Grüße
Boris
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Wzut

Zitat von: KölnSolar am 08 Januar 2020, 10:22:17
1. Wer weiß etwas mehr über die genannten Funktionen und kann Infos über Einsatzzweck, Nebenwirkungen, Beispiele, Unterschiede sagen/verlinken ?
2. Seht Ihr es nicht auch so, dass die periodisch pullenden Informationsbeschaffer-Funktionen GRUNDSÄTZLICH ausgelagert gehören und dass wir dazu einen
1. ich verwende in einigen meiner Module BlockingCall. Child erzeugen, Daten holen & verarbeiten, Child sterben lassen. IMHO elegant, das Thema Speicherverbrauch kam hier vermutlich zu Unrecht in die Diskussion und hat sich ja inzwischen mit den neuen HTTPMod Version erledigt.
Ich verwende BC aber in zwei meiner Module (MPD & SIP) auch als Dauerläufer, da jederzeit von externen Quellen Daten anfallen können und ich die sofort an den Eltern Prozess durchreichen muß. Hier wäre eventuell eine andere Lösung (die ich allerdings nicht habe ) angebrachter.

2. Zustimmung, aber https://wiki.fhem.de/wiki/Blocking_Call reicht doch jetzt aus ? Es sei denn es gäbe Alternativen
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

zap

Ich bevorzuge SubProcess. Allerdings ist das eher für Dauerläufer im Hintergrund geeignet als für einmalige Aktionen, die FHEM nicht blockieren sollen. Dafür würde ich auch Blockingcall verwenden.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

KölnSolar

Hm, viel ist ja nicht zusammengekommen.  :'(

zu
Zitat1. Wer weiß etwas mehr über die genannten Funktionen und kann Infos über Einsatzzweck, Nebenwirkungen, Beispiele, Unterschiede sagen/verlinken ?
eigentlich nichts.
zu
Zitat2. Seht Ihr es nicht auch so, dass die periodisch pullenden Informationsbeschaffer-Funktionen GRUNDSÄTZLICH ausgelagert gehören und dass wir dazu einen "Entwicklungsleitfaden" haben sollten ?
eher Zustimmung, aber bei einer Rückmeldung und noch nicht einmal ein Daumen hoch....  :-\

@Wzut: Kannst Du das
ZitatSpeicherverbrauch kam hier vermutlich zu Unrecht in die Diskussion und hat sich ja inzwischen mit den neuen HTTPMod Version erledigt.
noch etwas näher ausführen, weil mir das als Gegenargument immer wieder entgegenkommt. Beobachten kann ich bei mir keine Probleme. Im Gegenteil: BlockingCall macht was es soll und der Hauptprocess schnurrt durch.

Und noch ein Beispiel zu meinem Wunsch zu 2. Um bei PV-Anlagen den tatsächlichen Verbrauch zu ermitteln benötigt es 2 devices. Wenn nun ein größerer(> 0,5s) Zeitraum zwischen der Abfrage der devices liegt, gibt es keine sinnvollen Werte mehr. Funkt ein "Langläufer" dazwischen, war es das.

Und noch etwas zur Klarstellung wonach ich suche: BlockingCall wird ja vermutlich deshalb kritisch wg. Speicherverbrauch beäugt, weil es eine Kopie des Hauptprozesses bereit stellt. Ich vermute, dass das notwendig ist, um eben auf sämtliche Daten aus FHEM zugreifen zu können. Ich suche aber etwas, wo FHEM gar keine(eine geringe) Rolle spielt. Ansonsten ähnlich der Arbeit mit BlockingCall.
Start mit Funktionsparametern-->Lesezugriffe(HTTP,File,DB,externe Softwareprozesse....) -> ggfs. Filterung u. rechenintensive Umrechnungen -> Rückgabe Daten an den Hauptprozess-> Beenden des Teilprozesses
Alternativ: Start eines "Nebenprozesses" mit einem define und Beendigung mit einem undefine; der "Nebenprozess" versorgt den Hauptprozess zyklisch mit Daten(dafür sind als Lösung SubProcess und CoProcess geeignet ?  :-\)
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Wzut

Thema Speicherverbrauch :
Ich bin da mit meinen Modulen zweimal in den Fokus geraten weil ich BC verwende, nun schaut es aber so aus als ob es am XML Parsen lag :
https://forum.fhem.de/index.php/topic,84372.msg1006307.html# du kannst ja mal alle 50 Seiten lesen.

Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

rudolfkoenig

ZitatHm, viel ist ja nicht zusammengekommen.
Es liegt vermutlich daran, das hier zur gleichen Zeit die gleiche Diskussion lief.

justme1968

also...

wichtig ist, das auslagern nicht als allheilmittel zu sehen. insegsammt muss dadurch ja nicht plötzlich weniger gemacht werden. in den aller meisten fällen ist auch im bezug auf blockieren das auslagern nicht nötig. nonblocking io und select sind sehr mächtig und können sehr viel mehr als die 'modernen' thread befürworter sehen wollen. d.h. es muss aus performance gründen nicht grundsätzlich ausgelagert werden. fhem ist normalerweise nicht durch die rechenleistung begrenz sondern durch io. das auslagern beschleunigt cpu wenn es mehr als einen prozessor (kern) gibt, aber io nur bedingt.

wenn es aus bestimmten gründen (s.u.) doch nötig ist etwas zu parallelisieren oder auzulagern sind (lang laufende) prozesse deutlich einfacher und weniger fehler anfällig als threads.

egal wie dieser externe prozess gestarted wird (fork, exec, perl lesen aus prozess, ...) es ist immer der gleiche grundlegende mechanismus der den neuen prozess erzeugt und dabei potentiell den kompletten speicher dupliziert. d.h. auch: egal ob open($fh, "$cmd|" ) oder explizites fork und exec, unter der haube ist beides identisch! ersteres startet unter umständen sogar noch mehr prozesse weil noch ein shell dazwischen kommt.

in linux sollte eigentlich copy-on-write dafür sorgen das der overhead sich in grenzen hält. ich benutze aktuell kein system bei dem der hauptspeicher so knapp ist das ein fork fehlschlagen würde. daher kann ich hierzu nicht viel sagen.

ebenfalls wichtig: sobald geforkt wurde kann der kind prozess (ausser loggen) nicht mehr auf fhem interne daten zugreifen bzw. erhält nur veraltete versionen. er kann auch direkt keine readings oder anderes mehr aktualisieren. d.h. alles was auswikrungen im 'haupt' fhem haben soll muss irgendwie dorthin kommuniziert werden. der geforkte prozess erhält auch keine events mehr und muss diese anders besorgen wenn er sie braucht!

das forken MUSS mit fhemFork() passieren. sonst werden benutze resource nicht korrekt freigegeben oder geschlossen -> restart schlägt wegen benutzer ports oder usb devices fehl. selbst bei allen vorsichtsmassnahmen bleibt rereadcfg problematisch. aber das ist ein anderes problem und rereadcfg gehört sowieso abgeschafft :).

da ganze ist auch erst mal nicht mit windows installationen kompatibel.

unterm strich: auslagern ist ganz sicher kein muss sondern eine einzelfall entscheidung. wer sich nicht sicher ist was er tut braucht es in der regel nicht. ausser ihm wird ganz konkret das gegenteil bewiesen :).


gründe für das auslagern:
- mehr kern prozessor soll für (aufwändige) berechnungen genutz ausgelastet werden
  das trifft für fhem in der regel nicht zu.

- kapseln/stabilität, dafür wäre ein generelles framework tatsächlich schön.
  im entwickler bereich gibt es dafür einen uralten proof of concecpt für ein sanboxing
  bei dem jeweils keine gruppen von zusammengehörenden modulen in eine eigene sandbox
  ausgelagert werden. habe es aber dann doch nicht weiterferfolgt da alle alten module
  die direkt auf z.b. {READINGS} zugreifen auf Readings routinen aktualisiert werden müssten.

- es wird eine perl lib verwendet die nur blocking arbeitet oder sich nicht in die fhem select
  loop einhängen lässt (1-wire, imap,...)

- es wird ein externes binary verendet. z.b. weil es bereits funktionalität in nicht-perl bibliotheken
  gibt die genutz werden sollen. aktuell vor allem node interessant.

- ... ?



BlockingCall: ist hauptsächlich auf nicht besonders häufige und kurze aktionen in perl ausgerichtet.
                    kommunikation zurück erfolgt über telnet. d.h. ip. daten müssen ascii sein. d.h.
                    bei kompexeren dingen z.b. json. kein weitere support für loggen, eigene logfiles, ...

SubProcess: hauptsächlich für länger dauernde dinge in perl, kommunikation über explizite descriptoren, ascii oder binär
                   kein weitere support für loggen, eigene logfiles, ...

CoProcess: hauptsächlich für länger dauernde dinge in einem eigenen prozess der nicht perl sein muss.
                 kommunikation über stdio. ascii oder binär. bietet support für eigene log files, rotation, ...
                 unterstützt in verbindung  mit dem npmjs modul das aktualiseren externer node libs und
                 den neu start des moduls danach.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

KölnSolar

ZitatEs liegt vermutlich daran, das hier zur gleichen Zeit die gleiche Diskussion lief
....und ich mind. 2-mal zum übergreifenden Thema "Parallelprozess" auf diesen Thread verwies ::) ;D
ich kopier mal zusammen
ZitatZitat
Nun bin ich noch mehr bestärkt, dass wir Mechanismen wie BlockingCall ohne Nebenwirkungen brauchen.

Das ist ein netter Wunsch, aber mW gibt es keine Loesung ohne Nebenwirkungen.

Ich kenne 4, alle nicht unproblematisch:
- select. Keine Loesung fuer CPU-Intensive Aufgaben, kann den Rest blockieren durch Bibliotheksfunktionen.
- fork (z.Bsp. BlockingCall): braucht viel Speicher, Starten und Datenaustausch zwischen den Prozessen aufwendig.
- multithreading. Erfordert eine spezielle perl Version, und ist nichts fuer unerfahrene Programmierer.
- alles was blockieren kann, kriegt das Ergebnis per Callback (z.Bsp. HttpUtils_NonblockingGet). Nachteile siehe select.
ZitatMan muss das immer abwägen. Thread oder fork hat auch "Kosten". Bei fork muss das OS eine Kopie des gesamten Prozesses erstellen, man muss die Daten in den Hauptprozess zurückholen und die Fehleranfälligkeit steigt. Siehe blockingcall und Speicher.

zwei Links zum ersten einlesen zu non-blocking
https://docstore.mik.ua/orelly/perl4/cook/ch07_21.htm
https://www.cs.ait.ac.th/~on/O/oreilly/perl/cookbook/ch07_14.htm

Zitat von: herrmannj am 09 Januar 2020, 23:04:39
Ja klar. Ich persönlich halte das so: bis 500ms geht klar, 1000ms wenn es nur alle Stunden mal zum tragen kommt, aber da wirds schon eng.Blocking Call benutzt fork. Es gibt keine simple rule. Ist halt wie immer: je komplexer die verwendete Technik ist, desto höher das Risiko das es zu Problemen kommt. Und thread und fork sind komplex. Ja. Genau. die Select loop  :) ;)

Zitat von: rudolfkoenig am 10 Januar 2020, 11:09:23
Was hier noch nicht erwaehnt wurde, aber den Widerstand der "Select-Neulinge" verstaendlich macht:

Bei der select Methode muss der Programmierer, wem diese Methode neu ist, umdenken: die gewuenschte Zeile steht nicht nach dem Aufruf der readline Funktion, "in der naechsten Zele" zur Verfuegung, sondern irgendwannmal spaeter:

Blockierend:line = readline("filename");
process(line);
Mt select:
select_readline("filename", sub(line) { process(line) });
[... hier ist line nicht bekannt...]


Wenn man unterschiedliche Daten benoetigt, die blockierend besorgt werden muessen, dann wird das Ganze etwas unschoen: entweder verwendet man eine Reihe von ineinander geschachtelten Funktionen (sog. "Calback Hell"), oder die Funktion wird als Status-Maschine gebaut.
Im "ueblichen" FHEM physikalischen/IO-Modul (wie 00_CUL.pm oder 00_MQTT2_SERVER.pm) entspricht das sub von oben der $hash->{ReadFn}. Diese implementiert eine Status-Maschine: sysread fuegt die gelesenen Daten zum bisherigen $hash->{BUF} hinzu, und wenn BUF danach kein komplettes Hardware-Telegramm ergibt (z.Bsp. NL fehlt noch), dann hoert ReadFn auf, und wartet auf dem naechsten Aufruf.

Bei existierenden, blockierenden Code kann der Umbau in die "select Methode" aufwendig sein, und der Umbau zu fork oder thread einfacher.
Auf der anderen Seite verursacht die select Methode weniger Probleme als fork, und ist einfacher zu beherrschen als thread.

Zitat von: herrmannj am 10 Januar 2020, 12:05:51
ehrlich, ich glaube das fork oder thread nur oberflächlich betrachtet "einfacher" sind. Wenn man das "richtig" machen möchte dann muss man so viele Spezialfälle beachten (offene handles, zombies). _Plus_ man muss unterschiedliche OS Versionen(2), Perl Versionen und perl Module (json?)(1)(3) testen. Und am Ende kommt doch jemand (user) mit irgendeinem exotischen Symptom um die Ecke um man muss den kram aufwendig versuchen zu debuggen.

Gerade in der "Phase" des Lernens ist der fork/thread Code dann meistens von stack overflow "inspiriert". Man freut sich dass das läuft ohne exakt zu verstehen warum - und dann soll man da plötzlich noch debuggen. Schwierig

Select erfordert es (Zustimmung) _anders_ den Programm Ablauf zu denken. Aber: nach 2-3 Tagen Kopfschmerzen ;) läuft das plötzlich.

(1): es gibt einige Perl module bei denen es entscheidend ist ob die vor oder nach dem fork geladen werden. Bei einem fork wird der ganze (perl/fhem) Prozess im Speicher ge-cloned. Json war früher berüchtigt dafür, sowohl threads als auch fork, unvorhersagbare Effekte auszulösen. (2) Windows zb kann nämlich gar keinen fork. Dort wird das als thread emuliert. (3)https://stackoverflow.com/questions/46793885/perl-json-fails-if-a-thread-is-started
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

KölnSolar

Danke Euch allen für die konstruktiven Beiträge. Ich habe auf jeden Fall dazugelernt u. werde mich mal mit subprocess auseinandersetzen.

Von meiner "Maximalforderung" bin ich etwas abgekommen. Ich fand gerade Andres sehr ausführlichen Beitrag hilfreich, in dem er eingangs recht treffend formuliert
Zitatauslagern nicht als allheilmittel zu sehen. insegsammt muss dadurch ja nicht plötzlich weniger gemacht werden. in den aller meisten fällen ist auch im bezug auf blockieren das auslagern nicht nötig. nonblocking io und select sind sehr mächtig und können sehr viel mehr als die 'modernen' thread befürworter sehen wollen. d.h. es muss aus performance gründen nicht grundsätzlich ausgelagert werden. fhem ist normalerweise nicht durch die rechenleistung begrenz sondern durch io. das auslagern beschleunigt cpu wenn es mehr als einen prozessor (kern) gibt, aber io nur bedingt.

Auch Jörgs
Zitatbis 500ms geht klar, 1000ms wenn es nur alle Stunden mal zum tragen kommt, aber da wirds schon eng.Blocking Call benutzt fork. Es gibt keine simple rule. Ist halt wie immer: je komplexer die verwendete Technik ist, desto höher das Risiko das es zu Problemen kommt
fand ich gut, wenngleich ich die Grenzwerte etwas niedriger sehe.  ;)

Jetzt gilt es 2 Dinge zu tun:
1. Das Thema weiter verfolgen und einen "Leitfaden" zu entwickeln, damit das hier nicht verstaubt
2. freezemon weiterzuentwickeln, um noch eindeutiger Ursachen u. verantwortliche Module ans Licht zu bringen

RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

KernSani

Ich klinke mich mal kurz ein - HTTPUtils kommt zwar im Titel vor, wird aber nicht diskutiert. Ich bin immer davon ausgegangen (ohne darüber nachzudenken), dass nonBlockingGet auch irgendwie forked o.ä. Habe jetzt aber (nachdem ich ins Coding geschaut habe) festgestellt, dass das garnicht der Fall ist, sondern dass IO::Socket::INET sich um den non-blocking Teil kümmert. Was da passiert übersteigt allerdings meinen Horizont. Kann mir das jemand in einfachen Worten grob erklären? Ich frage insbesondere vor dem Hintergrund (siehe auch Markus 2. Punkt) dass es scheinbar Fälle gibt, in denen FHEM zu blockieren scheint, obwohl nonBlockingGet genutzt wird.
 
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

justme1968

statt blockieren zu lesen (d.h. zu warten bis daten da sind) wird nur gesagt: ,ich möchte lesen. sag mir bescheid wenn daten da sind. ich mache so lange etwas anderes.'

,das sag mir bescheid' erfolgt über select. deswegen select loop. da werden alle descriptoren eingehängt von denen etwas kommen könnte und fhem legt sich so lange schlafen wie das system keine daten zum lesen meldet aber höchstens bis zum nächsten timeout für at, sleep und internal timer.

das non blocking get nutzt zum lesen diesen mechanismus. d.h. wenn man es richtig verwendet wird kann es nicht blockieren.

nur durch einen seiteneffekt wie z.b. die dns namens auflösung durch standard routinen die warten statt der fhem version die ebenfall diesen mechanismus nutzt. deswegen hatte rudi oben von verschachteln gesprochen.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

zap

Zitat von: justme1968 am 14 Januar 2020, 11:14:19
SubProcess: hauptsächlich für länger dauernde dinge in perl, kommunikation über stdio, d.h. ebenfalls ascii.
                   kein weitere support für loggen, eigene logfiles, ...

Kleine Korrektur: Die Kommunikation zwischen Child und Parent Process läuft über Netzwerk Sockets. Binär oder asccii.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

justme1968

nicht ganz. der binär teil ist richtig. genauer:

SubProcess und CoProcess verwenden beide socketpair um den ipc kanal zu erzeugen. d.h. man kann tatsächlich ascii oder binär daten austauschen. SubProcess bietet den beiden prozessen die deskriptoren zum lesen und schreiben explizit an, CoProcess biegt stdin, stdout und stderr darauf um und ermöglicht so, das externe prozesse einfach eingebunden werden können und/oder das die externen ausgaben automatisch im (fhem) log erscheinen.

aber: socketpair wird in beiden für unix domain stream sockets verwendet. die sind lokal und laufen nicht übers netzwerk. d.h. nicht über den tcp stack und auch nicht über localhost sondern eher wie eine pipe in der shell oder ein fifo (aber eben unbenannt).

BlockingCall verwenden dagegen tatsächlich tcp/ip über localhost d.h. den netzwerk stack.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

DS_Starter

Guten Abend,

über den Winter habe ich mir vorgenommen zu schauen ob ich DbLog auf SubProcess umgestellt bekomme und ob es dann praktikabel managebar ist.
Ich denke da insbesondere an solche Dinge wie Connect-Management, Queue-Management (z.B. Eventhaltung bei DB down), DB Fehlerbehandlung und solche Dinge.

Leider habe ich noch keinerlei Erfahrungen mit Subprocess und muß mir das Handling erst aneignen. Aber ich denke es wäre eine gute Sache im Umfeld DbLog.
Es werden sich sicherlich eine Menge Fragen ergeben und ich würde diesen Thread gern dafür nutzen sofern die Problemstellung den Umgang mit SubProcess betrifft.

VG,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter