Autor Thema: Dauer Read eines files 1 Sek.; Ursache[geklärt], Optimierung[unmöglich] ?  (Gelesen 886 mal)

Offline herrmannj

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 5243
Zitat
Das ist für mich die falsche Argumentation. Wenns genau im Augenblick läuft, wenn es an der Tür klingelt(Taster) und ich gerade in den Garten gehe, verpasse ich das, weil Alexa nicht rechtzeitig mit mir gesprochen hat. ;) Da hilft dann nicht die Diskussion über Eintrittswahrscheinlichkeit, sondern es gilt es von vorneherein auszuschließen(sofern machbar).
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.
Zitat
Und hier scheiden sich die Geister. WZUT "behauptet" im anderen Thread, das wäre gelöst.  ??? Und schon frage ich mich, was stimmt denn nun und was bedeutet das konkret. Was sind die do's u. dont's beim Einsatz ?
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.
Zitat
Allerdings hoffte ich mehr darauf, dass wir bereits irgendwo etwas haben, es nur nicht genutzt wird.
Ja. Genau. die Select loop  :) ;)
smartVisu mit fronthem, einiges an HM, RFXTRX, Oregon, CUL, Homeeasy, ganz viele LED + Diverse

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 21547
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.

Offline herrmannj

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 5243
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
« Letzte Änderung: 10 Januar 2020, 12:18:01 von herrmannj »
smartVisu mit fronthem, einiges an HM, RFXTRX, Oregon, CUL, Homeeasy, ganz viele LED + Diverse

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3865
ich hab Eure Beiträge mit "allgemeinem" Inhalt in den anderen Thread kopiert.

Zitat
Widerstand der "Select-Neulinge"
kein Widerstand. Probiert, getestet, keine Daten  :'(

Grund
Zitat
The kernel module starts a 12-bit temperature conversation whenever you read the w1_slave file (which is specified to take no more than 750 ms). Not sure about the polling intervals at which it searches the bus for new devices, though
(und vor ein paar Jahren hatte ich das schonmal gelesen.....nur vergessen)
RPi3/2 buster/stretch-STV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-CUL868-FS20A4-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty-Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 21547
Zitat
kein Widerstand. Probiert, getestet, keine Daten
Das liegt aber dann an der Implementierung.
Da hier offensichtlich viel Herzblut vergossen wird: ich biete es das Modul in dieser Hinsicht zu fixen, wenn du es mir zusendest.

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3865
Dank Dir fürs Angebot.
Zitat
Das liegt aber dann an der Implementierung.
Ich befürchte.
Zitat
offensichtlich viel Herzblut vergossen wird
Och es geht. Mir reicht schon, dass ich verstanden habe, dass das ein Sonderfall ist u. es mir das Select-Thema näher gebracht hat.
Zitat
ich biete es das Modul in dieser Hinsicht zu fixen
Viel lieber hätte ich Deine knappen Ressourcen verschwendet, um zu verstehen, warum trotz global dnsServer bei hohem Netzwerktraffic ein blockierendes Verhalten auftreten könnte. Einstieg hier müsste zum Verständnis der Situation reichen.
Grüße Markus
RPi3/2 buster/stretch-STV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-CUL868-FS20A4-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty-Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 21547
Na gut :)

 

decade-submarginal