Äquivalent zu fork() unter Windows?

[BUG]

Zitat von Angel4585:

Warum braucht man unter Linux ein fork()?

Fork "kopiert" afaik den kompletten Adressraum eines Programmes und erstellt einen neuen Prozess. Das Tolle an Fork ist, das das Kopieren eine "faule" (lazy) Operation ist. Das heißt, Speicherseiten, die keiner der beiden Prozesse nach dem Fork schreibt, teilen sich den physischen Speicher. Das ist eine ziemlich unkompliziert Möglichkeit, am Programmstart geladene Ressourcen im Speicher unter mehreren Prozessen zu teilen.
Andererseits ist der neue Kindprozess eben ein eigenständiger Prozess mit allem was dazu gehört. Die Prozesse können abstürzen ohne den anderen zu beeinflussen.

[Angel4585]

Aber wenn fork() eine Technik ist mit der man so viel erreichen kann, warum schmeisst man sie einfach so aus dem System?
Bzw. durch welche Technik wurde sie ersetzt? Reines Threading?

[Furtbichler]

Threading ist resourcenschonender und schneller beim Wechseln. fork() wurde afaik vor 40 Jahren erfunden, was nicht per se gegen diese Funktion spricht. Aber eben auch nicht für sie.

[Medium]

Sie scheint mir schlicht nicht notwendig zu sein. Ich bin bis heute auch prima ohne sie ausgekommen (auch wenn ich mir durchaus Einsätze vorstellen kann). Zudem ist es gut möglich, dass unter Windows dafür einige heftige Verränkungen gebraucht würden, die das OS prinzipbedingt nicht oder nur sehr unperformant/"hacky" her gibt. Gerade das copy-on-write Verhalten kann ich mit im virtuellen Speicher von Windows als echte Aufgabe vorstellen. Wenn es unabdingbar wäre, hätten die Entwickler der Welt MS sicherlich schon dort hin getrieben. Das Thread-Modell scheint hier aber alle Wünsche zu erfüllen, und ist seit der NT-Linie fester und bewährter Bestandteil.
(Man entschuldige meine Ignoranz, aber wenn ich nicht irre wurden Threads in Linux hingegen erst eingeführt, nach dem es Leute in der Windows-Welt als für doch echt ziemlich praktisch befunden hatten. IMHO kannte Linux lange keine Threads in diesem Sinne. Daher würde für mich anders herum ein Schuh draus. Das in Klammern hier basiert jedoch auf Halbwissen.) Dennoch wüsste ich aktuell nicht, was ich mit Forks machen könnte, was ich nicht mindestens ähnlich komfortabel mit Threads (oder eben wirklich multiplen Prozessinstanzen) nicht auch erledigen könnte.

[BUG]

Zitat von Medium:

Gerade das copy-on-write Verhalten kann ich mit im virtuellen Speicher von Windows als echte Aufgabe vorstellen.

Das wird das geringste Problem sein. Kompliziert ist bei der Verwaltung von virtuellen Speicher eigentlich "nur" die Entscheidung, welche Seiten nun im physischen Speicher bleiben und welche ausgeswapt werden.
Meiner Meinung nach passen Threads und fork als Konzept einfach nicht wirklich zueinander. Und es ist ja nicht nur die Frage, wie mit Threads beim forken umgegangen wird, sondern auch mit anderen Ressourcen (Locks, Handles/Filedescriptoren, usw.).

Ich halte fork (auch heute) für ein interessantes Konzept, insbesondere weil man effizient und ziemlich einfach Speicher mit komplexen Datentypen teilen kann und Trennung in unterschiedliche Addressräume hat. Das Nächste was in diese Richtung gehen würde, wäre Rumgebastel mit Memory Mapped Files.

Aber die meisten Anwendungen sind mit Threads wohl sehr viel besser bedient.