Dauer Read eines files 1 Sek.; Ursache[geklärt], Optimierung[unmöglich] ?

[herrmannj]

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.

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.

Allerdings hoffte ich mehr darauf, dass wir bereits irgendwo etwas haben, es nur nicht genutzt wird.

Ja. Genau. die Select loop 

[rudolfkoenig]

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:

Code Auswählen Erweitern

line = readline("filename");
process(line);
Mt select:

Code Auswählen Erweitern

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.

[herrmannj]

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

[KölnSolar]

ich hab Eure Beiträge mit "allgemeinem" Inhalt in den anderen Thread kopiert.

Widerstand der "Select-Neulinge"

kein Widerstand. Probiert, getestet, keine Daten 

Grund

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)

[rudolfkoenig]

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.

[KölnSolar]

Dank Dir fürs Angebot.

Das liegt aber dann an der Implementierung.

Ich befürchte.

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.

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

[rudolfkoenig]

Na gut