vorschlag: PRESENCE serialisierung der scans

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

Vorheriges Thema - Nächstes Thema

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.