Diskussion:Fork (Unix)

Relevanz

wenn ich das richtig verstehe, handelt es sich hierbei um einen prozess/befehl einer programmiersprache?? denke, das gehört nicht hierher in die wikipedia- D0c Stört aber doch auch nicht? Du musst es ja nicht lesen.

fork() spielt eine grosse Rolle beim Erstellen von Services, ftp waere zum Beispiel ohne dieses wichtige System-Feature serverseitig wesentlich umstaendlicher zu implementieren, es ist eine der grossen Vorteile von Unix gegenueber Windows, insbesondere im Bezug auf das Internet und Client-/Server-Architektur. Das Beispiel behandelt zwar Syntax und Verwendung in der Programmiersprache C, die Nutzung ist aber nicht auf C beschraenkt.

Die Geschichte mit dem Kopieren der Umgebungsvariablen hat jemand 'rausgenommen, vermutlich, weil es unvollstaendig wiedergibt, was wirklich passiert. Tatsaechlich werden sowohl ausfuehrbarer Code als auch Daten des Parent-Prozesses dupliziert, mit Ausnahme der Prozess-ID, der Parent-Prozess-ID und des Rueckgabewertes der Funktion fork() ist der Kindprozess also ein vollstaendiger Clone. -- 194.8.205.24 09:40, 30. Jan. 2008 (CET)

Quelltext vs. Maschinencode

In der vorherigen Version des Artikels war die Rede davon, dass ein fork() neben den Umgebungsvariablen und dem Befehlszähler auch den Quelltext in den neuen Prozess kopiert. Ich habe das in Maschinencode geändert, weil es dieser ist, der vom Prozessor ausgeführt wird, nicht der Quellcode. Im Allgemeinen hat ein Programm auch gar keinen Zugriff auf seinen eigenen Quelltext, sondern besteht aus den Assembler-Instruktionen. --Robb der Physiker 13:47, 14. Jan. 2007 (CET)

Nicht ganz. Assembler entspricht zwar mehr (einfache Assembler) oder weniger (Macro-Assembler) den direkt ausfuehrbaren Maschinen-Anweisungen, ist aber mnemonisch umgeschluesselt, so dass man sich nicht die Hexadezimalcodes sondern (halbwegs) lesbare Tokens merken muss. Assembler ist also ebenfalls Quellcode. Um es fuer die CPU verdaulich zu machen, wird es in Maschinencode umgesetzt. Assembler kommt der Tatsache aber immhin naeher als Quellcode. -- 194.8.205.24 09:46, 30. Jan. 2008 (CET)

hier laufen scheinbar nur 2 prozesse

hiho ich hab mal eben den c code probiert und jeweils immer getpid() ausgeben lassen und dabei gemerkt dass hier eigentlich nur 2 prozesse laufen (also kind und vater) war das auch die intention oder wollte man 10 verschiedene prozesse haben ?

Es wird nur einmal geforked, also kann es nur zwei Prozesse geben. Wir wollen hier ja keine Forkbomb haben ;-) --Robb der Physiker 23:44, 6. Mai 2008 (CEST)

Verbesserungsidee

Offensichtlich ist es noch nicht beim ersten Mal Lesen eingängig, was fork eigentlich genau macht.

Mir wäre der gemachte Sprung in den Kernel und das Entstehen zweier parallel laufender Prozesse (Vater,Sohn) ohne die als Referenz angegebene Annimation zu fork auch völlig entgangen.

Ohne hier rumpfuschen zu wollen, schlage ich vor dem Programcode ein Paar Zeilen zu ergänzen, sodass am Schluss noch eine Ausgabe gemacht wird, welcher Prozess (Vater,Sohn) länger gelebt hat.

Denn wenn am Ende nochmals dasteht, "Der Vater(prozess) hat seinen Sohn(prozess) überlebt." (Oder vice versa) muss wohl jedem klar sein, dass es zwei parallele Prozesse gegeben hat; und außerdem wird die Analogie zu Vater-Sohn noch deutlicher.

Bin leider nicht mehr so ganz drin in C, sonst würd ich die paar Zeilen selbst hinklatschen :(

Joshua Ham (nicht signierter Beitrag von 92.229.171.0 (Diskussion | Beiträge) 21:51, 11. Feb. 2010 (CET))

Kritik an fork()

Während fork() eie genial einfacher Systemaufruf ist, handelt man sich damit doch auch Nachteile ein: Da unter Unix-artigen Betriebssystemen ein execve() fehlt, welches einen neuen Prozess erzeugt, ist die übliche Programmierung, ganz salopp:

if (!fork()) execve(...);

Der Nachteil ist nun, dass vom aktuellen Prozess eine Kopie erstellt wird, die anschließend vernichtet wird. Um mit dem Problem zu leben gibt es eine ganze Büchersammlung von Methoden im Betriebssystem, um diese Art von Rechenleistungsvernichtung erträglich zu machen. Nun ja, hätte man doch (CreateProcess() :-)

--Henrik Haftmann (Diskussion) 18:31, 6. Aug. 2013 (CEST)

Das dürfte dann aber eine ganz schön angestaubte Büchersammlung sein, denn so wie du es hier beschreibst (und man es ehrlich gesagt auch dem etwas simpel gehaltenen Artikel entnehmen könnte), sprich, dass bei fork() tatsächlich ein kompletter Prozess kopiert würde, das war mal so, bei den ganz alten Unixes. Auf m.W. allen modernen Systemen gibt es dagegen wenig Anlass, ein CreateProcess() zu vermissen und u.U. deshalb vermutl. auch kein CreateProcess. ;) Abgeholfen wird dem einerseits dadurch, dass das Codesegment grundsätzlich schreibgeschützt ist, also ohne weiteres geteilt werden kann, ohne kopiert werden zu müssen und andererseits dadurch, dass bei Daten und Heap gemäß Copy-on-Write verfahren wird; es kommt also auch hierbei nicht zu einer unmittelbaren alles-oder-nichts Kopie. Vielmehr verweisen beide Prozesse zunächst auf dieselben Speicherbereiche und erst wenn einer der beiden Faults fährt, werden die entspr. Pages kopiert und die Seitentabelle angepasst. -ZT (Diskussion) 16:08, 10. Sep. 2015 (CEST)

verwendete Sprachregelungen

Auch hier wurden erstklassig verständliche Fachausdrücke in unverständliches "Deutsch" übersetzt (oder liegts an mir, daß ich zwar weiß, was ein instruction counter ist, aber den Begriff "Befehlszähler" noch nie gehört habe?). Wir werden vermutlich die Eindeutschungswut der Nicht-Experten, die sich hier Bahn bricht, nicht mehr eindämmen, aber damit das Ganze wenigstens einheitlich unverständlich wird und nicht nur die englischen, sondern auch die lateinischen, griechischen und sonstigen Fremdworte vervolkssprachlicht werden, schlage ich also folgende weitere Änderungen vor:

Programm: Anweisungsliste
Prozess: Anweisungslistenausführung
Dateien: Sachverhaltsbeschreibungsansammlung(en)
Dateideskriptoren: Sachverhaltsbeschreibungsansammlungbeschreiber
Kopie: Abbuntmetallung ("Kupfer" ist leider auch Latein, also bei fremden Sprachen abgekupfert)
Animation: Bewegtbildbeschreibung
--bakunin (Diskussion) 15:02, 16. Aug. 2017 (CEST)