Gibt es eine möglichkeit den PID von den script die jetzt ausgefuhrt wird zu erkennen?
Und auch : Könnte es eine möglichkeit geben um fur ein script die PID’s die zu diesem script gehören auf zu listen ?
Mit dieser implementation hätte man die möglichkeit ein inteligentes ding zu machen, die parallell (in multi-thread model) laufen könnte und dabei (uber PID) seine settings bei halten könnte.
Ein vorbild:
Ich habe 5 mögliche trigger die ein script ausfuhren lasst.
Diesem script könnte also max. 5x simultan angerufen werden.
Gehen wir davon aus das das script sichselber zuruck anruft um nach die laufzeit eine weile zu warten (1s zb.) und im 2en durchlauf bestätigung gibt das er durchgelaufen hat. Hierfur braucht man in ein array von variablen die das script angerufen haben. (Gedenke : multi threading). Den Array beeinhalt auch die priorität von die angerufene variablen. Das hiesse also das man - wenn der timer ablauft, den variablen suchen könnte die mit höchster priorität (0 das höchste) die damals das script angerufen hat. :o Capiche ?
Nach das das script fur dem 2en mal gelaufen hat alle variablen prio-1 und hopla… stehen die script-argumente bereit fur den näechsten durchlauf.
Gibt es inzwischen einem neuen trigger : kein problem, das script-array wird zusätzlich gefullt mit die variable und die niedrigste bisherige priorität.
Und jetzt kommt es : die priorität ist eigentlich den event-timer vom script.
Das hiesse also das man :
a) zig verschiedene timer-events fur ein script programmieren könnte… oder mann schiebt verschiedene prioritäten mit die gleiche variable im array ‚ab-zu-arbeitene-event-triggers‘ : bekommt man auf bestimmte zeiten den gleichem durchlauf so wie timer-wizzard aber in multi-thread.
b) man ein einziges script mehrmals anrufen durfte in die zukunft - wobei die verschiedene (event-) variablen anerkannt werden.
Was denkste ? Machbar ? Interessant fur das IPS ? Nur ‚Fredje‘ denkt in multi-threading ?
Habe noch einige argumente auf 'm tank … also schiesse los
Grusse,
Fredje
–edit–
Am nächsten Tag : „Boa Fredje ! Das ist ein Script-Event-timer-queue wobei die Zeitdifferensen und triggers beibehalten werden. Einfach !“
– ende edit–
Hmm… ohne es jetzt komplett verstanden zu haben. Ein paar Dinge:
Diesem script könnte also max. 5x simultan angerufen werden.
> Das ist so nicht richtig. Du kannst ja mal ein Script anlegen mit sleep(10) und es öfters triggern… Dann startet es auch so oft wie du es getriggert hat, bis du keine Threads mehr frei hast. Threadlocking und Synchronization kannst du per IPS_Semaphore* schaffen.
> Ich würde nur im Ausnahmenfall versuchen Scripte per Sleep warten zu lassen. Wenn man sich das angewöhnt, ärgert man sich, dass Sachen nicht mehr funktionieren, weil alle Thread Slots belegt sind.
> Eine Kommunikation zwischen einzelnen Script Threads kannst du Notfalls über IPS Variablen machen, ich sehe da aber irgendwie keinen wirklichen Vorteil, da man mit dem Prinzip des Triggerns viel Transparenter gestalten kann.
Fredje meint, wenn ein Skript im gleichen Moment von 5 verschiedenen Variablen getriggert wird, das Skript aber erst nach einer Prioritätsliste abgearbeitet wird, sprich das Skript abarbeiten mit dem neuen Inhalt der Variable (die das Skript angetriggert hat) das in der Prioritätsliste ganz oben steht, dann, 2. , 3. usw.
Er will nur vermeiden dass das ganze einfach nur sequentiell nach dem Zufallsprinzip abgearbeitet wird.
Man könnte so das Verhalten des Variableninhaltes steuern je nachdem, was zuerst ausgeführt wird.
Ein Vergleich wäre in der Mathematik: Punkt kommt vor Strich Rechnungen, nur eben mit dem Feature, das man es steuren kann, was zuerst kommt !
In unseren üblichen (Windows-) PCs gibt es soetwas wie „Gleichzeitigkeit“ nicht. Selbst wenn alle möglichen Events gleichzeitig auftreten, müssen diese dennoch einzeln in den Systemablauf „eingereiht“ werden. Die dabei auftretende Reihenfolge ist von allerlei Faktoren abhängig, auf die man tunlichst keinen Einfluss (Process Priority) nehmen sollte.
Selbst auf Multi-Prozessor Maschinen gibt es eine übergeordnete Instanz, die die Tasks oder Threads an die jeweilige CPU delegiert. Auf diese Weise gibt es auch dort eine nicht vorherbestimmbare Reihenfolge.
Eine wichtige Tatsache darf man dabei ebenfalls nicht aus dem Auge verlieren:
Eine CPU arbeitet im Nanosekunden-Bereich, IPS mit der Script-Sprache PHP dagegen eher im Sekunden-Bereich.
Ein Script ist kein kompiliertes Programm (wie C++ oder Pascal), sondern es wird erst zur Laufzeit interpretierend abgearbeitet.
Es ist daher um Größenordnungen langsamer.
Daher kann man sagen: Alles, was sich innerhalb einiger hundert Millisekunden ereignet geschieht praktisch gleichzeitig.
Daraus folgt: Die Script-Abarbeitung auf Thread-Ebene herunterbrechen zu wollen ist maßlos überzogen. IPS ist keine Realtime-Umgebung.
Das von euch genannte Beispiel:
5 Ereignisse treten gleichzeitig auf.
Diese werden in einer für uns zufällig erscheinenden Reihenfolge abgearbeitet.
Um eine bestimmte Reihenfolge zu erzwingen, kann man mit den bereits vorhandenen Mitteln eine einfache Prioritäten-Steuerung realisieren.
Eine If-Abfrage ermittelt, ob alle Voraussetzungen für die plangemäße Abarbeitung erfüllt sind.
Ist dies nicht der Fall, so kann sich das Script selbst nach z.B. 2 Sekunden erneut triggern, um die Voraussetzungen noch einmal zu prüfen.
Natürlich sind auch die von Paresy genannten Verfahren geeignet.
Für ein verbessertes Fein-Tuning wäre es wahrscheinlich ausreichend den Event-Timer mit einer Auflösung von z.B. 100ms auszustatten.
Ich würde eher sagen, dass eine Scriptausführung incl Triggern ein paar Millisekunden dauert. Wenn euch Interssiert wie alles genau passiert und was in welcher Reihenfolge abgearbeitet wird, guckt euch die Logs unter Debug an. Dort ist die Zeit mit Millisekunden aufgelöst mit den einzelnen Messages, wann die Variable sich geändert hat, über Thread start, bis Thread end.
Gleichzeitig starten die Threads nie, es kann aber passieren, dass die parallel zueinander laufen, bzw eine Operation, die zu einem Zeitpunkt nur von einem Thread benutzt werden kann doppelt benutzt wird. Bestes Beispiel ist dabei FileIO. Es kann immer nur einer eine Datei im Write Zugriff haben.
Wenn eine Variable sich verändert, werden die Scripte in einer bestimmten Reihenfolge getriggert. Diese kann man unter Variables->Edit Variable einsehen.
Wenn ein Script über meherere Variablen getriggert wird, wird das Script in der Reihenfolge ausgeführt in der sich die Variablen verändert haben. Es ist nicht Möglich, dass sich mehrere Variablen im selben Zeitpunkt ändern.
Wenn sich die Variable binen Momenten ändert, sodass die Zeit zwischen Thread start und bis zur Ausführung der ersten Funktion nicht reicht, könnte ihr mit $IPS_VALUE den Inhalt der Variable zum Zeitpunkt des Triggerns abrufen.
Ich vermute aber, dass diese Thematik in den seltensten Fällen überhaupt relevant ist.
In ‚C‘ kommt es hierauf an : ich möchte programmatorisch ein script anrufen können und in den anruf gleich die argumente mitgeben könnnen die das script steueren soll (denke an include(„scriptname“, „$IPS_SENDER“, „$var“, „$varwert“, …, 8s) NUR das in der zeit versetzt (die 8 secunden).
Das fuhrt aber dazu das es eine queue geben könnte von an zu rufene scripte mit derren argumente. Das script oder die internen abwicklung (IPS) soll wissen welcher als nächste dran ist. Priorität.
In bin dabei ein dimmer-script (DMX-based) an zu fertigen, aber brauche ein instrument die wenn das script lauft, der neuen ausfuhr davon bestimmt werden kann, aber geplannt in die zukunft. Analog an SetScriptTImer(); nur mit mehr argemente.
Deshalb meine oberige - ich gebe zu - absoluut unklarer kwatsch. Hoffe hier wird es besser…
Script: ABC, wartet laut Parameter delay und gibt Parameter var1 aus.
sleep($delay);
echo $var1;
Da Script ABC wartet, wird jeweils ein Slot dafür belegt, was bei übermäßigem Gebraucht euer IPS verlangsamen/träger machen wird.
Übrigens gibt es für das was du machen willst in C oder sonst einer Programmiersprache meines Wissens nach kein Konstrukt. Da wirst du auch etwas selber bauen müssen.
[quote=GGGss;19380]
In bin dabei ein dimmer-script (DMX-based) an zu fertigen, aber brauche ein instrument die wenn das script lauft, der neuen ausfuhr davon bestimmt werden kann, aber geplannt in die zukunft. Analog an SetScriptTImer(); nur mit mehr argemente.
[quote]
So ganz habe ich noch nicht verstanden was du willst - ich denke aber das ist für deine Moodlights?
Beschreibe mal denn Effekt den du erreichen willst… vieleicht fällt mir dazu auch was ein.
Habe es jetzt gelöst durch das script secundenlich zu triggeren und den array aus-zu-fuhrenen-scripte-und-derren-argument (pfieeuw) in einer .ini file dabei zu halten. Das script zorgt auch fur den haushalt dieser .ini file.
funzt…
Jetzt kann ich in einem script SetIntensity() befehle uber zeit bestätigen lassen durch variable zu setzen wenn der dim-wert seinen target ereicht hat.
In mein script werden bis zu 15 SetIntensity befehle gesendet. Alle habe einem anderen durchlauf-zeit. Neue befehle an diese geräte durfen nur neu gesendet werden wenn die wirklich diesem wert erreicht haben (also nach x sekunden). Dan nur darf der naechste im queue kommen.
Dachte mir : wäre ne nette ausbau von die script-event timer. Deshalb
oder mann schiebt verschiedene prioritäten mit die gleiche variable im array ‚ab-zu-arbeitene-event-triggers‘ : bekommt man auf bestimmte zeiten den gleichem durchlauf so wie timer-wizzard aber in multi-thread.