Autor Thema: vorschlag: PRESENCE serialisierung der scans  (Gelesen 4084 mal)

Offline Markus Bloch

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 3683
Antw:vorschlag: PRESENCE serialisierung der scans
« Antwort #15 am: 27 Juli 2016, 23:18:30 »
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.

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)

Online frank

  • Hero Member
  • *****
  • Beiträge: 10674
Antw:vorschlag: PRESENCE serialisierung der scans
« Antwort #16 am: 27 Juli 2016, 23:52:09 »
Zitat
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 ...."
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

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 21006
Antw:vorschlag: PRESENCE serialisierung der scans
« Antwort #17 am: 28 Juli 2016, 14:14:09 »
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
« Letzte Änderung: 28 Juli 2016, 14:29:50 von justme1968 »
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 21006
Antw:vorschlag: PRESENCE serialisierung der scans
« Antwort #18 am: 28 Juli 2016, 14:30:00 »
habs korrigiert...
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 24893
Antw:vorschlag: PRESENCE serialisierung der scans
« Antwort #19 am: 28 Juli 2016, 15:36:00 »
Komme erst in einer Woche dazu, es naeher anzuschauen...

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 24893
Antw:vorschlag: PRESENCE serialisierung der scans
« Antwort #20 am: 07 August 2016, 18:51:18 »
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.