Äquivalent zu fork() unter Windows?

[Angel4585]

Guten Tag!

Was wäre ein Äquivalent zu fork() von Linux, unter Windows?

Für diejenigen, die fork() nicht kennen: Was ist fork()?
fork() erzeugt einen neuen Prozess.
Entweder einen neuen Prozess des aufrufenden Programms.
Ohne weitere Parameter wird der dann auch an der gleichen Stelle im Programm fortgeführt.
Oder man lädt nach dem fork() einen anderen Programmteil, welcher dann ausgeführt wird.

Unter Windows nutzt man Threads - die es natürlich unter Linux ebenfalls gibt.

Aber:
Warum braucht Windows kein fork()?
Warum braucht man unter Linux ein fork()?
Gibt es unter Windows ein Äquvivalent?(Damit mein ich kein "Workaround" a la "Cygwin nutzen")

[mkinzler]

Da Windows seit Win2000 das POSIX Prozessmodell nicht mehr unterstützt, gibt es keinen 100% Pendant zu fork()

[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.

[JamesTKirk]

Zitat von mkinzler:

Da Windows seit Win2000 das POSIX Prozessmodell nicht mehr unterstützt, gibt es keinen 100% Pendant zu fork()

Ehm... ich merke nur mal nebenbei an, dass ich unter Windows 7 das POSIX Subsystem (auch genannt Services for Unix Applications) am Laufen habe, was die Weiterführung des alten POSIX Systems unter Windows 2000 und älter ist. Beide nutzen dabei Funktionalität der Windows NT API, die sich von Windows 2000 bis zu 7 bzw. 8 nicht geändert hat (da Microsoft auch hier auf Abwärtskompatibilität acht nimmt).

Und die API Funktion, um die es hier speziell geht, ist NtCreateProcess (welche auch intern von CreateProcess verwendet wird, aber hier wird noch etwas mehr Verwaltungsaufwand betrieben). Die Deklaration schaut so aus:

Code:

NTSYSAPI
NTSTATUS
NTAPI
NtCreateProcess(
    OUT PHANDLE ProcessHandle,
    IN ACCESS_MASK DesiredAccess,
    IN POBJECT_ATTRIBUTES ObjectAttributes OPTIONAL,
    IN HANDLE ParentProcess,
    IN BOOLEAN InheritObjectTable,
    IN HANDLE SectionHandle OPTIONAL,
    IN HANDLE DebugPort OPTIONAL,
    IN HANDLE ExceptionPort OPTIONAL
    );

Der wichtigste Parameter im Zusammenhang mit fork() ist SectionHandle. Möchte man einen neuen Prozess basierend auf einer anderen Executable starten, so gibt man hier das Handle zur gemappten Executable an. Lässt man das jedoch weg, so forkt der Kernel den bei ParentProcess angegebenen Prozess. Im Win32 Subsystem muss man hier jetzt jedoch noch ein paar weitere Dinge machen (so muss man dem Subsystem den neuen Prozess von Hand bekannt machen, damit kernel32.dll, etc. für den neuen Prozess korrekt funktionieren). Seit Windows 2003 wird beim Forken übrigens auch eine Copy-On-Write Semantic für den Addressraum verwendet.

Falls jemand näheres hierzu wissen möchte, der sollte sich das Buch Windows NT/2000 Native API Reference anschauen, dort wird beschrieben, wie man einen Win32 Prozess forkt und was man dabei beachten muss. Was ich bisher jedoch noch nicht herausgefunden habe, ist wie man exec() am geschicktesten implementiert...

Gruß,
Sven