Thema: Flexibles und einfaches Prozess erzeugen

[erik.vikinger]

Hallo,

Zu deiner Pipe. Wow

Danke.

Gutes Bsp. wie sehr es vom Betrachter abhängt, ob etwas einfach oder kompliziert ist.

Wieso, was genau empfindest Du an meiner Idee kompliziert?

Die Lese-/Schreibpointer hätte ich aber schon den Prozessen überlassen, weil nen Sicherheitsgewinn hast du dadurch das du es in den Kernel packst auch nicht, weil der Prozess sich ja nicht dran halten muss.

Es geht dabei auch nicht um Sicherheit sondern darum das der Kernel dem Writer quasie einen Bereich in der Pipe zusichert und der Writer diesen Bereich ungestört füllen kann ohne auf andere Threads im selben Prozess Rücksicht nehmen zu müssen (es bedarf dafür keiner weiteren Synchronisation o.ä. und trotzdem können mehrere Threads parallel Messages in diese Pipe stellen). Das der Kernel in meinem Vorschlag immer gleich die halbe Pipe zusichert ist dafür aber etwas doof, hier wäre es eventuell geschickter wenn der Empfänger beim Create-Syscall auch die maximale Message-Größe vorgibt so das auch mehr als 2 Threads im Writer die Pipe befüllen können (falls das Verhältnis Pipe-Größe:maximale Message-Größe mehr als 2:1 beträgt). Diese Zusicherung gilt immer solange bis sie durch einen Send-Syscall benutzt wird (das übrig bleibende Stück kann dann wieder neu zugesichert werden) oder beim Wait-Syscall (da hier ja die vorangegangene Zusicherung durch den Kernel nicht groß genug war). Dem Wait-Syscall kann auch NULL übergeben werden so das nur eine neue Zusicherung mit einer gewissen Mindestgröße angefordert wird (damit ein weiterer Thread im Writer-Prozess an diesem Spiel mitmachen kann), die Mindestgröße könnte aber auch 0 sein so das nur eine vorhandene Zusicherung zurückgegeben wird. Die Zusicherung die vom Wait-Syscall kommt sollte auch nicht größer sein als die angeforderte Größe (der entsprechende Writer-Thread fordert ja schließlich X Bytes weil er genau weiß was er senden möchte) um die Pipe möglichst effizient nutzen zu können.

Einen expliziten Flush empfinde ich als unnötig weil ja jede geschriebene Message (durch den Send-Syscall) auch möglichst schnell zugestellt wird, der Kernel wartet nicht bis eine Menge X in der Pipe ist, das ergibt keinen Sinn.

Da komme ich nicht mit, wieso und wofür Double-Buffering?

Wenn Du eine Pipe immer ganz voll machst dann kann immer nur entweder der Writer oder der Reader arbeiten aber nie beide gleichzeitig. Deswegen würde ich die maximale Message-Größe deutlich kleiner ansetzen als die Größe der Pipe. Wenn beide parallel (auf unterschiedlichen CPUs) arbeiten können dann muss im Idealfall nie einer blockieren. Diese Idee ist eigentlich von Dir und die erscheint mir auch sehr nützlich in so einem Szenario.


Grüße
Erik

[FlashBurn]

Es geht dabei auch nicht um Sicherheit sondern darum das der Kernel dem Writer quasie einen Bereich in der Pipe zusichert und der Writer diesen Bereich ungestört füllen kann ohne auf andere Threads im selben Prozess Rücksicht nehmen zu müssen

Achso. Bei einer Pipe denke ich immer nur an eine 1:1 Beziehung und nicht an 1:n oder m:n. Ich denke es sollte auch nicht so schlimm sein, wenn meine nur eine 1:1 Beziehung zulässt. Ist halt ne Beschränkung die aber die Sache einfacher machen kann.

Einen expliziten Flush empfinde ich als unnötig weil ja jede geschriebene Message (durch den Send-Syscall) auch möglichst schnell zugestellt wird, der Kernel wartet nicht bis eine Menge X in der Pipe ist, das ergibt keinen Sinn.

Da habe ich mich dann wieder unglücklich ausgedrückt. Mit Flush war eigentlich das Senden (und damit den Reader "erstellen") gemeint.

Nur fällt mir auf, dass ich bei meiner Variante das Problem hätte, dass ich gar nicht mitbekomme wieviel nun in der Pipe noch frei ist, sprich ob der Reader auch schon fertig ist.
Diese ganzen Probleme hat man mit in den Kernel kopieren und wieder rauskopieren natürlich nicht

Ich überlege gerade, ob man die Lese-/Schreibpointer nicht einfach dem Reader und Writer überlässt, aber die ersten 4byte der Pipe sind ne UserSpace Semaphore. Der Writer würde die Semaphore inkrementieren (und wenn diese am Größenlimit ist, würde er in den Kernel gehen und blockieren) und der Reader würde sie dekrementieren (und wenn sie kleiner 0 ist, würde er blockieren).
Der Reader würde immer dann in den Kernel gehen und den eventuell blockierten Writer wecken, wenn die Semaphore vom Maximum um eins dekrementiert wird und der Writer würde immer dann in den Kernel gehen und den eventuell blockierten Reader wecken, wenn die Semaphore 0 wird. Dadurch würde man sich einige Syscalls sparen und man müsste weniger in den Kernel.

Wo genau siehst du denn ein Problem wenn der Writer den Wert der Semaphore beeinflussen kann? Ich meine sowas gibt es ja auch für Linux, also kann es nicht so schlimm sein Oder hängt es damit zusammen, weil man dadurch eventuell einen Service irgendwie schlecht beeinflussen kann?

Bei dieser Variante hätte man zwar keine Popup-Threads, aber ich würde meiner ursprünglichen Idee, dass 2 Threads parallel daran arbeiten können wieder näher bzw. hätte sie erreicht.

[erik.vikinger]

Hallo,

Ich denke es sollte auch nicht so schlimm sein, wenn meine nur eine 1:1 Beziehung zulässt. Ist halt ne Beschränkung die aber die Sache einfacher machen kann.

Kann man machen, ja, aber ich glaube nicht das der dadurch erzielbare Gewinn an Einfachheit wirklich nennenswert ist, insofern würde ich das als netten Zusatznutzen betrachten der nur wenig kostet.

Diese ganzen Probleme hat man mit in den Kernel kopieren und wieder rauskopieren natürlich nicht

Also bei meiner Idee würde der Kernel auch nichts kopieren, die Pipe (eigentlich ja nur ein bestimmter Bereich simplen Speichers) ist in beiden Prozessen identisch vorhanden (natürlich an unterschiedlichen virtuellen Adressen).

Ich überlege gerade, ob man die Lese-/Schreibpointer nicht einfach dem Reader und Writer überlässt, aber die ersten 4byte der Pipe sind ne UserSpace Semaphore....

Und da sind wir wieder an dem Punkt wo Du versuchst alles so kompliziert wie irgend möglich zu machen. Bei meiner Idee ist selbst bei mehreren Writer-Threads keinerlei zusätzliche Synchronisation im User-Space erforderlich und zwischen den zwei Prozessen erst recht nicht. Nebst dessen das wenn die zwei Prozesse sich per Semaphore o.ä. nur im User-Space synchronisieren das dann wieder die Möglichkeit für ein DoS besteht weil einer den anderen dauerhaft blockieren kann, auch soetwas ist bei meiner Idee grundsätzlich ausgeschlossen.

Dadurch würde man sich einige Syscalls sparen und man müsste weniger in den Kernel.

Wo würde man was sparen? Mit meiner Idee ist pro Message nur ein Syscall im Writer und nur ein Syscall im Reader erforderlich (also insgesamt nur 4 Ring-Wechsel), billiger wirst Du das bestimmt nicht bekommen.


Grüße
Erik


PS.: Linux benutzt ja auch das Konzept eines monolithischen Kernels, also kann das nicht so schlimm sein.  SCNR

[FlashBurn]

Also bei meiner Idee würde der Kernel auch nichts kopieren, die Pipe (eigentlich ja nur ein bestimmter Bereich simplen Speichers) ist in beiden Prozessen identisch vorhanden (natürlich an unterschiedlichen virtuellen Adressen).

Mit Problemen meinte ich dann auch sowas wie einfach ignorieren was der Kernel sagt und die alten Daten einfach überschreiben auch bei Multithreading zugriff auf eine Pipe würde sowas nicht möglich sein. Diese Variante wäre halt einfach sicherer, aber langsamer.

Und da sind wir wieder an dem Punkt wo Du versuchst alles so kompliziert wie irgend möglich zu machen.

Und ich sehe das halt anders Für mich ist diese Variante einfacher als das irgendwie im Kernel zu machen und irgendwelche Lücken zu berechnen und sowas. Du hast einfach nen Counter wieviele Bytes in der Pipe sind und dadurch weißt du ob weiter reinschreiben/rauslesen kannst oder nicht.

Nebst dessen das wenn die zwei Prozesse sich per Semaphore o.ä. nur im User-Space synchronisieren das dann wieder die Möglichkeit für ein DoS besteht weil einer den anderen dauerhaft blockieren kann, auch soetwas ist bei meiner Idee grundsätzlich ausgeschlossen.

Mal davon abgesehen das man sowas mit nem Timeout lösen kann (was ich aber grundsätzlich nicht mag), bin ich mir gerade nicht sicher wie das genau in Linux umgesetzt ist. Das werde ich mir morgen mal im Source-Code angucken. Ansonsten hast du recht.

Wo würde man was sparen? Mit meiner Idee ist pro Message nur ein Syscall im Writer und nur ein Syscall im Reader erforderlich (also insgesamt nur 4 Ring-Wechsel), billiger wirst Du das bestimmt nicht bekommen.

Wenn ich nun aber mehrere Msgs da reinschreibe besteht bei meiner Variante die Möglichkeit das gar nicht in den Kernel gegangen werden muss und der Reader fängt muss nicht erst anfangen wenn die Msg komplett geschrieben ist (könnte man aber trotzdem so machen).
Es könnte ja die Situation geben, dass der Writer Daten reinschreibt, den Reader aufweckt und noch während der Reader die Daten ausliest/mit ihnen arbeitet, kann er schon neue Daten reinschreiben ohne das er den Reader benachrichtigen muss.

Der Vorteil deiner Variante sind die Popup-Threads, ansonsten finde ich das mit den "Lücken" verwalten wesentlich komplizierter als ne normale Pipe. Eigentlich wäre deine Pipe mehr nen SlabAllocator malloc() mit Hilfe des Kernels. Denn so wie ich es verstanden habe, bekommt der Writer den Pointer ja vom Kernel und es kann durchaus sein, dass davor und danach noch Bereiche sind die schon älter sind.
Bei einer klassischen Pipe liest/schreibt man immer nacheinander rein ohne das da Lücken entstehen oder man aufpassen müsste wo man jetzt hinschreiben kann und wie groß der Bereich ist. Das ist also schon wesentlich komplizierter als es sein müsste.

PS.: Linux benutzt ja auch das Konzept eines monolithischen Kernels, also kann das nicht so schlimm sein. SCNR

Mal davon abgesehen, dass ein MikroKernel schöner vom Design her ist und theoretisch sicherer (wenn man denn ne IOMMU hat), aber auf jeden Fall stabiler (weil ein falscher Pointer im Treiber nicht im Kernel ist und das ganze System mitreißen muss) ist, kann man auch "schöne" Monolithen/Hybriden schreiben.

[Svenska]

sowohl Caller als auch Callee können das Sharing beenden.

Warum sollte der Caller das Sharing beenden wollen? Das bedeutet ja das er den Speicher verliert (quasi frei gibt) und das dürfte bei den üblichen Anwendungsmöglichkeiten wie read()/write() oder aio_read()/aio_write() eher nicht gewünscht sein, nebst dessen dass das nur mit ausgerichtetem Speicher funktioniert (man kann ja keine halben Pages frei geben).

Denk z.B. an die Schnittstelle zw. HW-Treiber und nächster Ebene. Da ist das Alignment unkritisch und auf deiner Arch. eh kein Thema.

Das ist richtig, betrifft aber nur den Fall mehrerer Threads innerhalb eines Prozesses auf einer einzelnen Maschine.

Aber gerade darum ging es doch, ihr habt doch gesagt das man bei Multithreading-Applikationen sehr schnell an einem Punkt ist wo das VFS saubere Kohärenz bieten muss.

Ein FD = muss Anwendung sich drum kümmern, nicht das VFS, da Daten bereits vorserialisiert, Threading irrelevant. Mehrere FDs werden interessant, egal ob eine oder mehrere Anwendungen. Darum ging es mir.

Für verteilte Systeme oder mehrere Prozesse in einem System hilft das nichts.

Das ist richtig aber eben wieder kein Alltagsszenario für ein Hobby-OS. Genau deswegen hätte ich ja gerne mal ein etwas alltäglicheres Beispiel.

Logfiles, wo mehrere reinschreiben und lesen können? NFS-Server? Definiere, was ein Hobby-OS NICHT kann. Können soll?

Gruß,
gesendet mit Bildschirmtastatur, daher kurz.

[FlashBurn]

Logfiles, wo mehrere reinschreiben und lesen können?

Was ist eigentlich das Problem, dass mehrere aus einer Datei lesen können (aber jeder sein eignen FD hat)? Ich sehe da erstmal keins. Was das Schreiben betrifft, muss das ganze im VFS serialisiert werden (und damit ist kein Mapping mehr möglich, sondern die zu schreibenden Daten müssen zuerst ins VFS).

Das 2 (oder mehr) Anwendungen den gleichen FD "sharen", damit z.B. immer am Ende der Datei geschrieben wird, könnte man doch dadurch "emulieren", dass man halt ne Art "APPEND_WRITE" Modus hat, der immer an das Dateiende anhängt, egal wo der Datei-Zeiger gerade ist, oder?

Was ich mir aber kaum vorstellen kann, ist dass es ein Szenario gibt, wo 2 (oder mehr) Anwendungen den gleichen FD "sharen" und aus der Datei lesen, weil da kommt ja nur Müll bei raus.
Das mehrere Threads daraus lesen kann ich mir noch vorstellen, aber da wäre ja nur ein FD in der libc (und die würde das serialisieren). Die Anwendung könnte z.B. mehrere Threads haben und alles lesen immer einen Block aus der Datei und verarbeiten den.

Sicherlich könnte man das Szenario auch auf mehrere Anwendungen ausdehnen, aber was soll das bringen, nur um die Ergebnisse dann wieder in eine neue Datei mit "APPEND_WRITE" zu schreiben?

Was Pipe´s betrifft, denke ich das sie so oder so ein Sicherheitsrisiko darstellen (genauso wie Semaphoren). Denn wenn der Reader blockiert und auf neue Daten wartet, braucht ja der Writer einfach keine mehr schicken und schon kann man nen Service "ärgern". Auch geht das ganze umgedreht, der Service will dem Clienten was schicken, der Client blockiert und wartet auf Daten und der Service schickt einfach keine.
Das ist aber nen Datenstruktur-Problem.

Ich musste dann auch feststellen, dass Futex´s nur für Intra-Process-Communication und nicht für Inter-Process-Communication sind und damit für meine Pipe´s eher ungeeignet. Bin mir nur nicht sicher, woran das liegt, ob daran das es so vllt einfacher ist oder zwecks irgendwelcher Sicherheitsprobleme.

[Svenska]

Logfiles, wo mehrere reinschreiben und lesen können?

Was ist eigentlich das Problem, dass mehrere aus einer Datei lesen können (aber jeder sein eignen FD hat)?

Bitte den Satz nochmal lesen. "Wo mehrere reinschreiben .... können."

Das Problem entsteht, wenn mehrere aus einer Datei lesen und die Datei gleichzeitig verändert wird. Möglicherweise von verschiedenen Prozessen.

Wenn es nur einen FD gibt, dann spielt jede Form von Multithreading keine Rolle, weil die Anwendung sich um die Serialisierung kümmern muss, um den FD konsistent zu halten. Interessant für das VFS sind nur die Fälle, in denen mit mehreren FDs gleichzeitig auf die gleiche Datei zugegriffen wird und zwar nicht nur lesend.

Man kann das zwar verbieten, wie Windows das tut (eine zum Schreiben geöffnete Datei ist exklusiv geöffnet), aber "schön" ist das dann nicht.

Gruß,
Svenska

[FlashBurn]

Bitte den Satz nochmal lesen. "Wo mehrere reinschreiben .... können."

Ich habe den Satz schon richtig gelesen, da steht aber auch was von mehreren die lesen und da ist es doch egal ob da nun einer und mehrere in die Datei schreiben, dass sollte immer kein Problem darstellen (es sei denn, mehrere die gleichzeitig mit dem selben FD, in verschiedenen Anwendungen, lesen).

Man kann das zwar verbieten, wie Windows das tut (eine zum Schreiben geöffnete Datei ist exklusiv geöffnet), aber "schön" ist das dann nicht.

Scheint aber zu funktionieren

Aber die Frage bleibt, abgesehen von einem "APPEND_WRITE", wo wird das noch verwendet (Schreiben oder auch Lesen mit dem selben FD in unterschiedlichen Anwendungen)?

[Svenska]

Identische FDs in verschiedenen Anwendungen ist relativ schwierig hinzukriegen... und wenn du es schaffst, ist es außerdem kaputt.
Und wenn du die Hälfte von einem Satz weglässt, verschwindet gelegentlich auch das Problem.

Wenn mehrere Prozesse bestimmte Daten aus einer Datei lesen, während mehrere andere Prozesse die gleichen Daten in die Datei reinschreiben - absolut gleichzeitig - wie verhält sich dein VFS dann? Werden die geschriebenen Daten in der endgültigen Datei schön durchmischt oder überlebt nur eine geschriebene Version, oder garkeine? Bekommen die Lesenden mal die eine, mal die andere Fassung der Daten oder bleibt für diese die Welt konsistent? Gelten die Daten als geschrieben, wenn die Datei geschlossen wurde, sie mit fsync() synchronisiert wurde, die Daten mit write() geschrieben wurden oder nach fünf Sekunden? Liest jeder Lesethread etwas anderes oder lesen alle immer das gleiche?

Oder kannst du Dateien prinzipiell nicht verändern, wenn sie schon geöffnet sind?

Probleme gibt es da schon genug, man muss sie nur suchen.

[FlashBurn]

Identische FDs in verschiedenen Anwendungen ist relativ schwierig hinzukriegen... und wenn du es schaffst, ist es außerdem kaputt.

Es ging z.B. um die Situation die bei einem fork() passiert und soweit ich es verstanden habe, nutzen dann Eltern und Kind-Prozess den gleichen FD mit dem gleichen Datei-Zeiger.

Wenn mehrere Prozesse bestimmte Daten aus einer Datei lesen, während mehrere andere Prozesse die gleichen Daten in die Datei reinschreiben - absolut gleichzeitig - wie verhält sich dein VFS dann? Werden die geschriebenen Daten in der endgültigen Datei schön durchmischt oder überlebt nur eine geschriebene Version, oder garkeine? Bekommen die Lesenden mal die eine, mal die andere Fassung der Daten oder bleibt für diese die Welt konsistent? Gelten die Daten als geschrieben, wenn die Datei geschlossen wurde, sie mit fsync() synchronisiert wurde, die Daten mit write() geschrieben wurden oder nach fünf Sekunden? Liest jeder Lesethread etwas anderes oder lesen alle immer das gleiche?

Sind alles durchaus Probleme, aber die eigentliche Frage ist doch, muss es wirklich möglich sein, dass mehrere Anwendungen in ein und die selbe Datei (mit dem gesharten Datei-Zeiger) schreiben können? Wo passiert das in der Praxis (bitte keine Log-Dateien)?

Selbst wenn mehrere Anwendung in ein und die selbe Datei schreiben (mit ihren eignen FDs), ist das irgendwo nötig? Zumal ich da ja sowieso sage, jedes write() gilt als eine atomare Einheit.
Wann die Daten wirklich in die Datei kommen, liegt doch am Programmierer. Denn in der libc wird ja gepuffert (wenn man es nicht abstellt).

Was das Lesen betrifft, kann ein vermischen alter und neuer Daten nur vermieden werden, wenn alles im VFS abläuft. Bei Memory-Mapped-Files wird es durchaus vorkommen, dass eine Anwendung einen Mix aus alten und neuen Daten liest.

Der einfachste Weg ist immernoch, nur exklusives Schreiben zuzulassen (mit der Ausnahme "APPEND_WRITE", obwohl sich auch diese Fälle auch mit exklusivem Schreiben lösen lassen). Denn mir erschließt sich immernoch nicht der Sinn hinter dem zeitgleichen Schreiben in eine Datei, das bringt doch nur Probleme mit sich.

[Svenska]

Identische FDs in verschiedenen Anwendungen ist relativ schwierig hinzukriegen... und wenn du es schaffst, ist es außerdem kaputt.

Es ging z.B. um die Situation die bei einem fork() passiert und soweit ich es verstanden habe, nutzen dann Eltern und Kind-Prozess den gleichen FD mit dem gleichen Datei-Zeiger.

Hmm. Meine Erfahrung mit (socket-)FDs ist, dass man den FD zweimal schließen muss, einmal im Elternteil und einmal im Kind, damit das Socket wirklich geschlossen ist.
Das klingt für mich mehr wie eine direkte Kopie des FDs, weniger wie der selbe. Jetzt bräuche ich jemanden, der die Details kennt.

Sind alles durchaus Probleme, aber die eigentliche Frage ist doch, muss es wirklich möglich sein, dass mehrere Anwendungen in ein und die selbe Datei (mit dem gesharten Datei-Zeiger) schreiben können?

Ich bezweifle, dass mit einem identischen FD mehrere Anwendungen gleichzeitig in eine Datei schreiben.

Selbst wenn mehrere Anwendung in ein und die selbe Datei schreiben (mit ihren eignen FDs), ist das irgendwo nötig? Zumal ich da ja sowieso sage, jedes write() gilt als eine atomare Einheit.

Beispiele findest du weiter oben. Wenn du, wie erik, der Meinung bist, dass sowas für ein Hobby-OS nicht nötig sei, dann solltest du das dokumentieren und ignorieren. Ansonsten behandeln. Wie, ist deine Sache.

Wann die Daten wirklich in die Datei kommen, liegt doch am Programmierer. Denn in der libc wird ja gepuffert (wenn man es nicht abstellt).

Die Frage ist, ob die Welt für jedes Programm konsistent bleibt oder eben nicht. Dazu gesellt sich dann die Frage, wie man diese Konsistenz definiert.

Gruß,
Svenska

[kevin]

Hmm. Meine Erfahrung mit (socket-)FDs ist, dass man den FD zweimal schließen muss, einmal im Elternteil und einmal im Kind, damit das Socket wirklich geschlossen ist.
Das klingt für mich mehr wie eine direkte Kopie des FDs, weniger wie der selbe. Jetzt bräuche ich jemanden, der die Details kennt.

Es ist ein einziger, mehrfach referenzierter Dateizeiger. Du hast wohl unsere ganzen Diskussionen über fork() nicht gelesen?

"The  child  process  shall  have its own copy of the parent's file descriptors.  Each of the child's file descriptors shall refer to the same open file description with the corresponding file descriptor of the parent."

Ich bezweifle, dass mit einem identischen FD mehrere Anwendungen gleichzeitig in eine Datei schreiben.

Ich glaube, dafür suchen wir auch seit längerem erfolglos einen sinnvollen Anwendungsfall, aber POSIX erlaubt es halt.

Selbst wenn mehrere Anwendung in ein und die selbe Datei schreiben (mit ihren eignen FDs), ist das irgendwo nötig? Zumal ich da ja sowieso sage, jedes write() gilt als eine atomare Einheit.

Ja, dafür gibt es Anwendungsfälle. Ob du die in deinem OS unterstützt oder nicht, ist deine Sache.

[FlashBurn]

Ich glaube, dafür suchen wir auch seit längerem erfolglos einen sinnvollen Anwendungsfall, aber POSIX erlaubt es halt.

Sprich wir könnten und also langsam mal darauf einigen das es eigentlich nicht nötig ist (sofern man nicht volle POSIX Kompatibilität anstrebt).

Ja, dafür gibt es Anwendungsfälle. Ob du die in deinem OS unterstützt oder nicht, ist deine Sache.

Ok, das ist doch mal ein Wort. Wissen das dann die Anwendungen alle, dass da noch mehr zur gleichen Zeit drin rumpfuschen?

Wenn dem so ist, würde ich grundsätzlich sagen, jede Datei wird fürs Schreiben exklusiv geöffnet, will man das mehrere Anwendungen in eine Datei schreiben können, muss man das explizit angeben. Ich denke das ist der beste Kompromiss.

"The  child  process  shall  have its own copy of the parent's file descriptors.  Each of the child's file descriptors shall refer to the same open file description with the corresponding file descriptor of the parent."

Ich tue mich schon immer mit Gesetzestexten schwer, aber wiederspricht sich das nicht?

Ich verstehe das so, das jedes Kind seine eigene Kopie == eigener FD mit Startwerten des originalen FDs. Der zweite Satz sagt dann aber wiederrum, dass die FD´s der Kinder auf die FD´s der Eltern zeigen sollen, was ja keine Kopie wäre. Was denn nun?
Zumal würde das nicht auch ne Kette geben der man folgen müsste, weil der FD der Eltern kann ja wieder auf den FD der Großeltern zeigen usw.

[kevin]

Eine Open File Description ist klassischerweise eine Struktur im Kernel, die eine geöffnete Datei beschreibt und zum Beispiel den Dateizeiger enthält. Der Userspace kommt damit nicht in Kontakt. Der File Descriptor ist ein Integer, der auf eine Open File Description gemappt ist. Das bekommt der Userspace mit, und davon hat jeder Prozess seinen eigenen Satz. Bei einem dup() ist es da gleiche, da kriegst du auch einen neuen FD für die Open File Description im Kernel.

Deine Fragen, was Programme im allgemeinen tun und wissen und so weiter kann man einfach nicht beantworten. Programme tun irgendwas und wenn es ein beabsichtigtes oder unbeabsichtigtes Feature gibt, werden Programme es früher oder später in einer mehr oder weniger kriminellen Weise ausnutzen.