Differences

This shows you the differences between two versions of the page.

--- computer:make [2017-08-26 00:36] – created skrupellos
+++ computer:make [2020-11-18 18:11] (current) – external edit 127.0.0.1
@@ Line 27: / Line 27: @@
   * Zwei Tasks, die zusammen ausgeführt werden konnten, haben die selbe Datei geschrieben.
   * Ein Task hat von einer Datei gelesen, die ein anderer geschrieben hat, welche zur selben Zeit hätten ausgeführt werden können.
+Diese Konflikte müssen erkannt werden und zu einem Fehler führen.
+Dadurch ist ein konsistent wiederholbarer Bauprozess möglich, gleich welches Grad an paralelität eristiert.
+Damit erkannt wird, welche Dateien gelesen und geschrieben werden, müssen die Zugriffe der gestarteten Bauprozesse Überwacht werden.
+Dabei sollten destruktive Zugriffe unterbrechbar sein (um um Zustimmeng des Nutzers zu fragen).
+Die gelesenen und geschriebenen Dateien werden Protokolliert (dependencies von ''*.c'').
+Zudem werden die Bentzen resourcen protokolliert um beim nächsten durchgang den grad an möglicher Paralelität genauer zu bestimmen.
+===== Weitere Überlegungen =====
+Sind Ein- und Ausgabedateien von Tasks das richtige Mas um die Baureihenfolge zu bestimmen?
+  * Vor der Ausführng sind nicht alle Ein- und Ausgabedateien eines Tasks bekannt.
+  * Pieline aus Modifikationen __einer__ Datei: Wie sollen die Schritte angeordnet werden?
+=> ggf. ausschließliches/zusätliches matching von Ausführbaren Tasks:
+  * ''in := (($1.tpl)[tplGenerator])''
+  * ''in := ([createEmail])''
+Tasks werden mit einer leeren umgebung ausgeführt.
+Umgebungsvariablen müssen explizit durchgereicht werden.
+Der Task wird standartmäsig zum 1.1.1970 ausfeührt.
+Andere Daten müssen explizit durchgereicht werden.
+Was wird mit Netzwerkverbindungen gemacht? Verbieten, Whitelists, Fragen, hashen (problem TLS), proxy (nur HTTP).
+Was soll mit Symlinks passieren? Was, wenn sich ein Symlink von einer zur nächsten Ausführung ändert?
+Siehe auch Gentoo's ''sandbox'' und Debian's ''fakeroot''.
+Beim Mergen Der Task-Overlays in den Master-Overlay nicht exakt wie weine DB-Vorgehen (nur tatsächlich paralell ausgeführte Tasks (transaktionnen) auf Konflikte testen), sondern alle aktionen von Tasks beachten, die hätten parallel ausgeführt werden können.
+Das master-overlay darf nicht direkt auf den sourcen liegen, sondern auf einem Snapshot derer, so kann man während dem bauen an den sourcen weiter arbeiten.
+Die Tasks dürfen auch nicht direkt auf dem master-overlay arbeiten.
+Nur Tasks, die aus dem selben Task-Set (Tasks die parallel ausgeführt werden dürfen) sind, können auf dem selben snapshot arbeiten.
+D.h. ein neuer master-snapshot muss nur erzeugt werden, wenn ein neues Taskset berechnet wird.
+Denn wenn die Tasks sagen, sie können gleichzeitig laufen, sind sie auch nicht auf die neusten files ihrer "mitläufer" angewiesen.
+===== Probleme die Auftreten können + Lösungen =====
+**Problem**: \\
+Tasks, bei denen die Ausgabedateien nicht vorher bekannt sind, erstellen die selbe Datei.
+**Lösung**: \\
+Fehler + Programmabbruch. Der Benutzer muss das Fixen.
+**Problem:** \\
+Tasks liest die selbe Datei, die es auch Schreibt.
+**Lösung:** \\
+Maximale anzahl der Ausführungen der Task-Instanz festlegen.
+**Problem** \\
+selbes file wird von verschiedenen Tasks bearbeitet (Filter/Produuktionskette).
+**Lösung:** \\
+  * Task + File als dependency angeben
+  * oder: Das verhalten verbieten und ein Task ruft mehrere Programme sequentiell auf.