vorschlag: PRESENCE serialisierung der scans

Begonnen von justme1968, 26 Juli 2016, 16:35:09

Vorheriges Thema - Nächstes Thema

justme1968

hallo markus,

anbei ein erster vorschlag wie man presence anfragen an verschiedene devices serialisieren könnte. erst mal nur für lan-ping eingebaut. zumindest function und alle anderen local scans wäre aber auch noch interessant.

- die idee ist ein PRESENCE device mit mehreren durch komma getrennten ip adressen zu konfigurieren.
- dieses haupt device startet jeweils reih um nacheinander die ping scans.
- die ergbniss readings werden dann in je einem eigenen PRESENCE device vom neuen mode dummy erzeugt.
- die threshold attribute lassen sich ebenfalls in diesem device setzen. der ping count auch.
- diese master instanz und die zugehörigen clients arbeiten dann wie 'normale' zweistufige fhem module zusammen
- es wird nur jeweils innerhalb eines master devices seerialisiert. mehrere master devices arbeiten wie bisher parallel.


offen:
- eventuell wäre es sinnvoll den fallback von client auf master auch für andere attribute noch einzubauen
- state timeout landet aktuell im master. der sollte auch in den client
- erweiterung für die anderen local scan varianten

wenn du prinzipiell mit einem patch in dieser art einverstanden bist würde ich die offenen punkte auch noch einbauen.

die sauberer lösung wäre zwar alles im einmal gestartet prozess zu machen, die änderungen wären aber sehr viel aufwändiger.

gruss
  andre

ps: ich habe unter mac os x das problem das die prozesse sich nicht direkt nach dem ende des ping beenden sondern alle bist zum timeout weiter existieren. d.h. sie melden den status zurück und irgendwann später kommt noch der timeout. das ist aber unabhängig von diesem patch.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

Markus Bloch

Hallo Andre,

danke für den Patch. Nur die Frage die sich mir stellt ist: Was ist der Vorteil dieses Konstrukts gegenüber mehrfach einzelnen PRESENCE Instanzen?

Gruß
Markus

PS: Dein PS klingt für mich nach einem generellen Problem von Blocking.pm unter Mac OS. Hast du ein ähnliches Verhalten auch bei deinem Modul speedtest?
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

justme1968

der vorteil ist das man sehr viele devices mit recht kurzem intervall abfragen kann ohne das potentiell mehrere scans vom gleichen typ parallel gestartet werden. das gleichzeitig starten kann kleinere systeme auslasten. auf fhem seite durch die prozesse und auf der seite des abgefragten systems z b. durch die snmp verbindungen.

gruss
  andre

ps: das muss ich mir noch anschauen. das verhalten ist  komisch.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

amithlon

Hallo,

ich frage jetzt mal direkt: wieviele Devices müssen es sein und wie dicht müssen die Abfragen sein, damit es erntshafte Probleme macht?
Und wie bekommt man soviele LAN-Geräte zustande?

Es interessiert mich wirklich, weil ich da noch viel mit Möglichkeiten und Grenzen von FHEM experimentiere und bestimmt noch was dazukommt.

Gruß aus Berlin
Michael


justme1968

das kommt drauf an...

es gibt einige berichtet das fritzboxen und kleiner raspberrys speicher probleme wenn zu ping scans parallel laufen.
hier bin ich zwar eigentlich der meinung das man einfach den fhem server etwas größer machen sollte.

aber bei mir ist es die abfrage von 6 devices per snmp die ab und an probleme auf dem router macht wenn die snmp anfragen parallel aufschlagen. den router größer zu machen ist nicht mehr ganz so einfach.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

Markus Bloch

Das Problem was ich hierbei sehe ist die Begrenzung die sich aus Anzahl der Geräte und Check-Intervall ergibt.

Das eigentliche Problem, warum Du diesen Patch vorschlägst ist die aktuell nicht kontrollierbare, parallele Ausführung von mehreren Ping-Definitionen.

Ich würde das Problem daher anders angehen und ein Attribut machen mit dem man folgende Modi einstellen kann:

  • Keine globale Parallele Ausführung (Modus-unabhängig)
  • keine Parallele Ausführung parallel zu anderen PRESENCE Definitionen im selben Modus
  • immer parallel ausführen (so wie jetzt auch)

Sobald ein neuer Check fällig wird, prüft jede einzelne Definition ob eine andere Definition (1. Option) gerade einen Check durchführt, bzw. ob eine Definition mit dem selben Mode (2. Option) einen Check durchführt. Wenn ja, erneute Prüfung in +1 Sekunden. Somit würden sich die Checks nach einem FHEM Start automatisch einpendeln so dass immer nur ein PRESENCE Check läuft (1. Option) bzw. nur ein Check pro Mode (2. Option).

Sofern das Attribut nicht gesetzt ist, wird der Check sofort gestartet ohne weitere Prüfung, wie bisher auch.

Das ganze setzt natürlich voraus, dass der Nutzer weis was er da tut und der Punkt- und Strichrechnung mächtig ist. Sollte man zu viele Checks in einem zu engen Intervall wollen und dann die 1. oder 2. Option gesetzt haben, würden Checks ausbleiben.


Als Alternativlösung könnte ich mir auch einen "Initial-Start-Delay" als optionales DefineFn Argument vorstellen. Nur da muss man selber rechnen damit nur 1 Check zur gleichen Zeit läuft.

Was meinst Du, Andre?

Gruß
Markus

Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

justme1968

das ist auch eine möglichkeit. aber auf den ersten blick kommt es mir aufwändiger und weniger transparente vor. auch gibt es aktuell in fhem keine gute möglichkeit globale attribute zu setzen.

der charm meines vorschlages  liegt glaube ich darin das er sich am normalen zweistufigen fhem konzept orientiert und das er zur laufzeit so gut wie keinen overhead hat. es müssen zu keinem zeitpunkt die anderen presence devices durchgegangen werden müssen.  es gibt auch keine möglichkeit (unabsichtlich) blödsinn zu konfigurieren.

ja das problem ist die nicht kontrollierbare parallele ausfuhrung. ich meine das die automatische serialisierung dür dad hochzählen des aktuellen index das problem besser löst als bei jedem start die globale laute durchzugehen und zu schauen.

das zweistufige konzept würde sich auch sehr gut auf die presenced/colectord variante ausdehnen lassen. es gäbe dann hier auch nur ein master device das sich zum colectord verbindet und die rein kommenden nachrichten an die dummy mode devices verteilt.

gruss
  andre

hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

Markus Bloch

#7
Hi Andre,

Zitat von: justme1968 am 26 Juli 2016, 19:45:38
das ist auch eine möglichkeit. aber auf den ersten blick kommt es mir aufwändiger und weniger transparente vor. auch gibt es aktuell in fhem keine gute möglichkeit globale attribute zu setzen.

Nunja, ich würde das auch nicht als globales Attribut sehen, sondern schon definitionsbezogen. Nur bei der Definition bei der man das setzt, prüft die einzelne Definition per $modules{PRESENCE}{defptr} (nicht per $defs, das wäre zu viel Overhead) ob gerade ein anderer Check läuft. So könnte man die Parallelität bei bestimmten Definitionen begrenzen und bei anderen außen vor lassen.

Zitat von: justme1968 am 26 Juli 2016, 19:45:38
der charm meines vorschlages  liegt glaube ich darin das er sich am normalen zweistufigen fhem konzept orientiert und das er zur laufzeit so gut wie keinen overhead hat. es müssen zu keinem zeitpunkt die anderen presence devices durchgegangen werden müssen.  es gibt auch keine möglichkeit (unabsichtlich) blödsinn zu konfigurieren.

ja das problem ist die nicht kontrollierbare parallele ausfuhrung. ich meine das die automatische serialisierung dür dad hochzählen des aktuellen index das problem besser löst als bei jedem start die globale laute durchzugehen und zu schauen.

das zweistufige konzept würde sich auch sehr gut auf die presenced/colectord variante ausdehnen lassen. es gäbe dann hier auch nur ein master device das sich zum colectord verbindet und die rein kommenden nachrichten an die dummy mode devices verteilt.

Ja, der Overhead ist bei dir durchaus geringer als das immer wieder Definitionsbezogen zu checken. Ich halte aber eine Prüfung von $modules{...}{defptr} vor jedem Start als vertretbar.

Wenn ich deinen Patch richtig lese, dann werden die Adressen nicht komplett im Check-Interval überprüft, sonder immer nur eine. Das bedeutet, wenn ich ein Check-Interval von 30 Sekunden definiere und 5 Adressen setze, dann wird jede Adresse aller 150 Sekunden geprüft, oder? Dazu kommt, dass der Check- und Present-Interval nicht korrekt beachtet werden, da eine Anwesenheit einer Adresse zu einem evtl. kürzeren Interval für die nächste Adresse im Array führt.

Ich tendiere daher eher zu der Attribut-Lösung, weil es nur eine Änderung an einer ganz spezifischen Stelle ist und keinerlei Änderungen an anderen Mechanismen innerhalb PRESENCE erfordert.

Da ich am Samstag weg fahre, würde ich das ganze daher auf nach meinen Urlaub vertagen, da ich jetzt ungern eine Änderung einchecken und dann eine Woche weg sein will.

Ich würde mich freuen, wenn noch weitere User ihre Meinung kundtun würden.

Gruß
Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

justme1968

lass dir zeit. überstürzen wäre falsch und mehrere meinungen wären tatsächlich gut.

es stimmt. das intervall hat in meinem patch eine etwas andere bedeutung und muss im Verhältnis deutlich kürzer gewählt werden. man könnte es auch einfach durch die anzahl teilen. die unterschiedlichen intervalle sind tatsächlich nicht berücksichtigt. die verwende ich nicht. die reihenfolge und die intervalle sind aber fest bestimmt.

bei deinem vorschlag sind die intervalle nicht mehr deterministisch. wenn eine instanz einen check starten will und feststellt das eine andere gerade läuft wird sie ja auch verschoben. potentiell auch mehrfach. das ist glaube ich ein prinzipielles problem ohne zentralen scheduler. ich meine das kann zu beliebigen race conditions und auch starvation führen.

noch ein argument gibt es für die zwei stufige variante bei function: eine function (in meinem fall die snmp abfrage) könnte auf einen schlag den status für alle devices zurück geben. das würde den overhead hier gewaltig reduzieren.

das mit dem nicht globalen attribut verstehe ich nicht ganz. wie soll das verhalten sein wenn es für unterschiedliche presence devices unterschiedlich gesetzt wird?

ansonsten erst mal schönen urlaub :)

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

frank

ZitatIch würde mich freuen, wenn noch weitere User ihre Meinung kundtun würden.

moin,

aus fritzbox sicht begrüsse ich natürlich die bestrebung parallele forks zu begrenzen, obwohl ich seit ein paar tagen auf pi3 umgezogen bin.  :)

ich hatte mir häufig gewünscht, dass es fhem-weit eine art "fork-management" gegeben hätte. es fehlt leider der überblick, welche module oder funktionen forken und wieviele instanzen insgesamt zufällig entstehen oder entstehen könnten. vor allem werden es immer mehr und besonders beim restart, oder zur vollen stunde, kann es sehr chaotisch werden.

meistens würde es ja schon genügen, dass man, bei gleichen intervallen, die startzeiten homogener verteilen könnte. oder das intervall würde vielleicht automatisch etwas verändert werden. ob ein lan ping nun exact alle 60s ausgelöst wird, oder manchmal alle 57s, ist doch bei presence anwendungen eigentlich unwichtig. hier könnte ein scheduler, der ab restart eine sinnvolle einteilung vornimmt, eine menge entschärfen. wenn man den devices noch prioritäten verpasst, könnten die intervalle vielleicht auch durch diesen scheduler in gewissen bereichen verändert werden.

andre's vorschlag verstehe ich so, dass man eine gruppe von devices, quasi in eine forkebene legt, und dort eventuell verzögerungen der check-intervalle entstehen können, da hier dann sequentiell gecheckt wird. sollte ich das richtig verstanden haben, finde ich so einen mechanismus sehr sinnvoll, da man dadurch die forks begrenzen könnte.

ideal wäre natürlich solche forkebenen mit anderen fork-modulen gemeinsam nutzen zu können. nur mal so für den hinterkopf.

grundsätzlich wäre auch das an-/abschalten von forks pro modul sinnig. manchmal möchte man lieber eine funktion nutzen, auch wenn sie vielleicht ein wenig blockiert, als dass das ganze system zusammenbricht und man dadurch das ganze modul gar nicht nutzen kann. daher habe ich zb presence schon länger nicht benutzen können. das wird sich in kürze aber wieder ändern.  ;)

auch eine verbesserte informationslage bezüglich des forkens würde sicher schon helfen, manche konstellationen besser zu konfigurieren. zb eine worst-case-fork-info: wieviele forks wurden wann gleichzeitig versucht zu starten? wann werden forks verworfen/verzögert?

gruss frank
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Markus Bloch

Vorschlag etwas genereller Natur:

Wie wärs, die Kontrolle der parrallelen Ausführung direkt in Blocking.pm an zentraler Stelle zu lösen und dort zu schedulen basierend auf einem global Parameter (maxParrallelForks bspw.)?

Jedesmal, wenn ein BlockingCall gestartet wird, wird ein Counter hochgezählt, sobald einer beendet oder abgebrochen wird, wird er wieder runtergezählt. Ein Start eines BlockingCalls wird verhindert sobald der Counter > maxParrallelForks steht und returniert einen Error von wegen "too many forks".

Das ganze wäre eine Lösung an zentraler Stelle und wirkt bei allen Modulen die Blocking verwenden. Das jeweilige Modul müsste sich dann drum kümmern den Call in X Sekunden Delay nochmal zu versuchen.

Was meint ihr?

Gruß
Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

justme1968

eine zentrale lösung wäre auch eine option, aber das wird noch komplizierter.

wie oben geschrieben glaube ich das es race conditions gibt und weder reihenfolge noch intervall oder überhaupt die ausführung zugesichert werden kann wenn jeder prozess für den neuen versuch selber verantwortlich ist und es keine queue mit prioritäten gibt. die z.b. auch hochgezählt werden müsste wenn ein aufruf nicht dran gekommen ist. ohne einen echten scheduler wird das nicht zuverlässig gehen. und das ist auf jeden fall overkill.

die einfache round robin variante ist glaube ich sehr viel weniger komplex, deterministisch und garantiert die ausführung.

eine kombination aus beidem könnte aber eine möglichkeit sein:
- es gibt ein globales attribut das die maximale anzahl der parallelen prozesse angibt
- ein BlockingCall wird nur dann direkt ausgeführt wenn die anzahl nich nicht erreicht ist
- wenn die anzahl erreicht ist kommt er in eine warteschlange
- wenn ein BlockingCall beendet wird, wird der nächste gestartet wenn es einen wartenden gibt. also fifo.

da ganze wäre deterministisch, an den einzelnen modulen wäre nichts zu ändern, nur das intervall ist nicht garantiert. das ist meiner meinung nach aber unkritisch. das intervall zu garantieren geht sowieso mit keiner variante so lange die resource begrenzt ist. ich könnte mir sogar vorstellen das sich die prozesse von ganz alleine mehr oder weniger gleichmässig verteilen und die warteschlange nach kurzer laufzeit recht kurz wird. dir priorität wäre die gesamt last so gering wie möglich zu halten, nicht ein fessters intervall zu garantieren. das ist für die kleinen systeme aber tatsächlich sinnvoll.

was damit leider weg fällt ist die kontrolle die jobs zu gruppieren. d.h. vom typ a darf maximaler einer laufen und vom typ b. a und b dürfen aber parallel laufen.

und auch das zweistufige konzept mit allen vor teilen :) (d.h. die oben angesprochene einzelne verbindung zum collectord und die möglichkeit mit einem function aufruf mehrere PRESENCE devices zurück zu liefern.)

wie wichtig das gruppieren ist weiss ich nicht das könnte man irgendwann über mehre queues einbauen wenn es tatsächlich relevant wird.

die zweistufigkeit könnte man auch komplett unabhängig von der prozess anzahl einbauen. ideen?

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

rudolfkoenig

Ich bin fuer ein einfaches FIFO (round robin bedeutet suspend oder vgl. und das haben wir nicht), ausbauen kann man es immer noch. Ein Haken ist das sichere Mitkriegen, dass der Prozess weg ist, das könnte noch nervig sein.

Markus Bloch

Zitat von: justme1968 am 27 Juli 2016, 18:58:46
eine zentrale lösung wäre auch eine option, aber das wird noch komplizierter.

wie oben geschrieben glaube ich das es race conditions gibt und weder reihenfolge noch intervall oder überhaupt die ausführung zugesichert werden kann wenn jeder prozess für den neuen versuch selber verantwortlich ist und es keine queue mit prioritäten gibt. die z.b. auch hochgezählt werden müsste wenn ein aufruf nicht dran gekommen ist. ohne einen echten scheduler wird das nicht zuverlässig gehen. und das ist auf jeden fall overkill.

die einfache round robin variante ist glaube ich sehr viel weniger komplex, deterministisch und garantiert die ausführung.

eine kombination aus beidem könnte aber eine möglichkeit sein:
- es gibt ein globales attribut das die maximale anzahl der parallelen prozesse angibt
- ein BlockingCall wird nur dann direkt ausgeführt wenn die anzahl nich nicht erreicht ist
- wenn die anzahl erreicht ist kommt er in eine warteschlange
- wenn ein BlockingCall beendet wird, wird der nächste gestartet wenn es einen wartenden gibt. also fifo.

da ganze wäre deterministisch, an den einzelnen modulen wäre nichts zu ändern, nur das intervall ist nicht garantiert. das ist meiner meinung nach aber unkritisch. das intervall zu garantieren geht sowieso mit keiner variante so lange die resource begrenzt ist. ich könnte mir sogar vorstellen das sich die prozesse von ganz alleine mehr oder weniger gleichmässig verteilen und die warteschlange nach kurzer laufzeit recht kurz wird. dir priorität wäre die gesamt last so gering wie möglich zu halten, nicht ein fessters intervall zu garantieren. das ist für die kleinen systeme aber tatsächlich sinnvoll.

Find ich gut die Idee.

Zitat von: justme1968 am 27 Juli 2016, 18:58:46
was damit leider weg fällt ist die kontrolle die jobs zu gruppieren. d.h. vom typ a darf maximaler einer laufen und vom typ b. a und b dürfen aber parallel laufen.

...

wie wichtig das gruppieren ist weiss ich nicht das könnte man irgendwann über mehre queues einbauen wenn es tatsächlich relevant wird.

Das sehe ich momentan eher als nice-to-have an. Die meisten User bei denen das kritisch wird, brauchen eine Möglichkeit zur Drosselung der parallelen Prozesse aufgrund von geringen RAM. Einen Bedarf zur Priorisierung und Gruppierung sehe ich da noch nicht.

Zitat von: justme1968 am 27 Juli 2016, 18:58:46
und auch das zweistufige konzept mit allen vor teilen :) (d.h. die oben angesprochene einzelne verbindung zum collectord und die möglichkeit mit einem function aufruf mehrere PRESENCE devices zurück zu liefern.)

...

die zweistufigkeit könnte man auch komplett unabhängig von der prozess anzahl einbauen. ideen?

Da bin ich nachwievor gespalten, da wir damit einen komplett anderen Ansatz fahren, den es so bisher noch nicht in FHEM gibt. Momentan sehe ich auch nur Dich (der Anforderer) als potentiellen Nutzer davon. Mein Bestreben ist es immer möglichst standardkonform innerhalb FHEM zu bleiben, damit ich selber weniger Arbeit habe beim nutzen von definierten Standardfunktionen, sowie einen geringeren User-Support im Forum. Dadurch ergeben sich wenig Sonderlocken die zu Fragen, Unverständnis und Aufwand im Forum führen.

Ich möchte ungern mit PRESENCE eine Sonderlocke bauen. Das in der Commandref/Wiki/Forum dem User 100% verständlich rüberzubringen, finde ich deutlich schwieriger. Und Sonderlocken machen immer Arbeit. ;-)

Lass uns mal abwarten, was weitere User/Developer zu dem Vorschlag sagen.

Siehst du momentan dieses Konstrukt nur für PRESENCE oder könntest Du Dir auch weitere Szenarien ausserhalb PRESENCE vorstellen?

Gruß
Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

justme1968

naja... zweistufige module gibt es schon einige. entweder explizit wie bei den ganzen logisch/physikalisch trennungen der diversen funk module oder auch innerhalb eines moduls wie bei netatmo, wirhings, plex, harmony, und noch ein paar mehr.

so sehr anders ist der ansatz also garnicht.

meine snmp anwendung ist ja auch nicht die einzige. die presenced/colectord anbindung über ein einziges socket und verteilung an mehrere passive presence devices zu machen ist schon der zweite. wenn man bluetooth nicht mehr über hcitool oder anderes externes binary anbindet sondern über das kernel socket wäre das noch eine anwendung. ich vermute es gibt noch mehr.

ich finde es ist nicht so sehr sonderlocke das der zusätzliche aufwand wirklich so groß ist wie du befürchtest.

wenn die serialisierung zentral passiert macht es das ganze ja auch eher noch einfacher.

aber ich will ja garnicht überreden. die zentrale serialisierung wäre ja auch schon mal was :).

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

Markus Bloch

Zitat von: justme1968 am 27 Juli 2016, 22:50:44
naja... zweistufige module gibt es schon einige. entweder explizit wie bei den ganzen logisch/physikalisch trennungen der diversen funk module oder auch innerhalb eines moduls wie bei netatmo, wirhings, plex, harmony, und noch ein paar mehr.

so sehr anders ist der ansatz also garnicht.

meine snmp anwendung ist ja auch nicht die einzige. die presenced/colectord anbindung über ein einziges socket und verteilung an mehrere passive presence devices zu machen ist schon der zweite. wenn man bluetooth nicht mehr über hcitool oder anderes externes binary anbindet sondern über das kernel socket wäre das noch eine anwendung. ich vermute es gibt noch mehr.

Das stimmt. Hier handelt es sich aber um Module, wo das 2-Stufen-Modell eine Trennung von Physikalischer Verbindung und logischen Entitäten notwendigerweise durchführt, da es nur so funktioniert bzw. Sinn macht.

Bei der Bluetooth-Implementation macht es durchaus Sinn zwischen Bluetooth-Stick und -Geräten zu trennen. Bei function/shellscript Modus könnte man es evtl. auch verwenden, sofern eine Funktion/Shellscript mehrere Devices zurückgeben (wie bei deinem SNMP-Beispiel). Das ist aber etwas für eklige Winter-Tage ;)

Für die anderen Modi wie Ping sehe ich jedoch keinen Grund für ein 2-Stufen-Modell, da hier keine Master/Slave-Situation gegeben ist.

Zitat von: justme1968 am 27 Juli 2016, 22:50:44
wenn die serialisierung zentral passiert macht es das ganze ja auch eher noch einfacher.

aber ich will ja garnicht überreden. die zentrale serialisierung wäre ja auch schon mal was :).

Eine zentrale Serialisierung halte ich durchaus für wichtig und notwendig. Im Forum gab es mittlerweile zu oft Meldungen von Usern deren PRESENCE Checks nicht ausgeführt werden aufgrund von "Cannot fork: no memory ...."

Lass uns das erstmal vorschlagen.

Gruß
Markus
Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

frank

ZitatEine zentrale Serialisierung halte ich durchaus für wichtig und notwendig. Im Forum gab es mittlerweile zu oft Meldungen von Usern deren PRESENCE Checks nicht ausgeführt werden aufgrund von "Cannot fork: no memory ...."
8)
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

justme1968

#17
anbei wäre mal eine aller erste idee wir man das zentral in Blockig.pm einbauen könnte.

es muss ein neues globales attribut BlockingCallMax angelegt werden. wenn es den wert 0 hat bleibt alles beim alten. sonst gibt es die maximale anzahl der gleichzeitig erlaubten blocking prozesse an.

irgendwo ist aber noch ein haken den ich nicht gefunden habe. eventuell hängt es mit meinem mac os x problem von oben in verbindung damit das der InternalTimer für den timeout nicht wieder gelöscht wird zusammen. d.h. er schlägt auf jeden fall immer zu. findet normalerweise dann halt nichts zum killen. in verbindung mit dem problem von oben führt das aber leider aktuell dazu das der prozess noch da ist. selbst wenn er sich schon zurück gemeldet und BlockingExit aufgerufen hat.

die prinzipielle idee ist die oben vorgeschlagenen:
- es gibt ein attribut BlockingCallMax das die maximale anzahl der gleichzeitig durch Blocking.pm gestarteten prozesse angibt
- unterhalb der grenze wird einfach wie bisher direkt gestartet
- wenn die grenze erreicht ist wird der aufruf in einen fifo gesteckt. der aufrufen erhält einen normalen $h hash zurück in dem pid auf WAITING gesetzt ist.
- wenn einer der gestarteten prozesse beendet oder geklillt wird kommt der nächste aus dem fifo an die reihe

vermutlich sollte man an ein paar stellen noch potentielle dead locks abfangen

bitte kommentieren und diskutieren.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

justme1968

hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

rudolfkoenig

Komme erst in einer Woche dazu, es naeher anzuschauen...

rudolfkoenig

An diesem Patch gefaellt mir nicht, dass keine abgeschossene oder exit() aufrufende Prozesse mitkriegt.

Ich habe jetzt eine andere Variante eingecheckt, wo alle ausstehende Prozesse in einem Hash gespeichert werden, und per kill 0 auf Existenz geprueft werden, entweder beim Exit oder per Timer. Habs unter OSX und Win7 getestet.

Das Attribut heisst blockingCallMax, ist auch dokumentiert.