nicht angemeldet
Hallo Christian,
Ist es wirklich so, daß ein neu geöffneter Prozess so dick ist wie ein anderer?
Jain.
Ah ... eine eindeutige Antwort :-)
Prinzipiell muss der komplette Speicher, auch das Datasegment, kopiert werden. Aber (jetzt
kommts): heutige Unixoide haben eine sehr geniale fork()-Implementation. Der Speicher wird
erst on demand kopiert. Heisst: der fork()-Aufruf selber ist erstmal nicht so teuer, es wird
nur eine neue Prozess-Umgebung angelegt. Erst wenn der neue Prozess auf die Daten zugreift
werden diese dann auch in den Speicherbereich des neuen Prozesses kopiert.
Hier habe ich ein kleines Verständnisproblem. Wie im weiteren Verlauf des Postings klar wird, wird ja das Codesegment dupliziert. Und das muss ja schon beim fork() passieren (spätestens wenn der fork aber in einem eigenen Task ausgeführt wird). Und eine solche Duplizierung finde ich schon recht teuer.
Ich vermute mal, daß der Programmcode zwischen den Prozessen eh geshared wird und es nur
ein eigener Stackframe/Dataframe pro Prozess gibt,Nein. Der Code muss für jeden Prozess ein weiteres mal in den Speicher geladen werden.
Das finde ich aber ungeschickt und ist aus meiner Sicht auch unnötig (es sei denn, man hat selbstmodifizierenden Code; wäre wenngleich auch ein schmutziger aber gangbarer Weg, um Informationen zwischen Child-Prozessen auszutauschen *lächel*).
Selbst Windows benutzt ja code-sharing (mindestens seit Version 3.0). Ich bezweifel deshalb mal stark, daß dies so ist.
Moment ... wozu hat man denn die Sourcen für Linux *nachles*
Mein Verdacht scheint sich zu bestätigen.
In linux/kernel/fork.c gibt es eine Funktion do_fork die das forking ausführt. Die enthält (soweit ich das überblicken kann) kein reload oder duplizieren von Programmcode.
Es wird eine neue Task-Struktur (task_struct; im wesentlichen interne Verwaltungsinformationen über den Task) angelegt sowie das Datensegment und das Stacksegment kopiert (bis auf den Rückgabewert des fork()-Aufrufes, anscheinend damit der Prozess erkennen kann ob er der Orginalprozess oder der geklonte Prozess ist oder weiß der Geier warum).
Wie das in brandaktuellen Version des Linux-Kernels gemacht wird, weiß ich nicht. Ich kann mir aber nicht vorstellen dass sie hier eine grundlegende Änderung vorgenommen haben.
so dass ein schlank konfigurierter httpd erstmal nicht soviel bringt. Richtig?
Doch, der bringt eine Menge ;-)
Der Overhead für den Stackframe sollte nicht allzu viel sein. Und Resourcen wie
DB-Verbindungen sind ohnehin Prozessgebunden und werden beim fork nicht dupliziert.
Klar werden sie. Es wird eine exakte, 100%ige Kopie von dem Prozess angelegt. Deshalb
sollte man mit offenen DB-Handles oder ähnlichem auch nicht fork()en, es wird ein- und
dieselbe Verbindung benutzt in dem Fall.
Ich würde sagen auch das ist so formuliert falsch.
Eher (so denk ich mir) ist es so, daß es ein httpd-Vaterprozess gibt der Anfragen entgegen nimmt und für diese zunächst ein eigenen Kindprozess erzeugt (sofern kein freier Kindprozess zur Verfügung steht) der diese Anfrage dann erst bearbeitet und die Antwort an den Browser zurückgibt. Die fork() wird also immer von diesem (keine Resourcen belegenden) Vaterprozess gemacht und nicht von einem laufenden Kindprozess der evtl. schon eine DB-Verbindung offen hat.
Gruß
MichaelB