Provided by:
manpages-de-dev_0.5-4.1ubuntu1_all 
BEZEICHNUNG
__clone - Erzeugt einen Kindprozess
ÜBERSICHT
#include <sched.h>
int __clone(int (*fn) (void *arg), void *child_stack, int flags, void
*arg)
BESCHREIBUNG
__clone erzeugt einen neuen Prozess, ähnlich wie fork(2) dies tut. Im
Gegensatz zu fork(2) erlaubt es __clone jedoch, dass der Kindprozess
Teile seines Kontextes mit dem Vaterprozess teilt. Dazu zählen
Speicherbereiche, die verwendeten Dateideskriptoren oder Signalhandler.
__clone wird in erster Linie dazu benutzt, um Threads zu
implementieren. Das sind mehrere parallel zueinander ablaufende
Programmstränge eines Prozesses in einem gemeinsamen Speicherbereich.
Wird ein Kindprozess erzeugt, führt er das Funktionsprogramm fn(arg)
aus. Das Argument fn zeigt auf eine Funktion, die vom Kindprozess zu
Beginn seiner Ausführung abgearbeitet wird. arg wird dieser Funktion
als Argument übergeben.
Kehrt die Funktion fn(arg) zurück, so beendet sich auch der gesamte
Kindprozess. Der Ganzzahlwert, der von fn zurückgeliefert wird,
entspricht dem Exit-Code des Kindprozesses. Der Kindprozess kann auch
durch ein explizites exit(1) oder durch ein geeignetes Signal beendet
werden.
Das Argument child_stack bestimmt den Ort des Stapelspeichers, der vom
Kindprozess verwendet wird. Da Vater- und Kindprozess sich
Speicherbereiche teilen können, ist es im allgemeinen nicht möglich,
beide auf demselben Stapelspeicher ablaufen zu lassen. Der Vaterprozess
muss daher einen Speicherbereich als Stapelspeicher für den Kindprozess
bereithalten und einen Zeiger darauf via __clone an den Kindprozess
übergeben. Mit Ausnahme von HP PA-Maschinen wächst der Stapelspeicher
auf allen von Linux unterstützten Prozessoren nach unten, so dass
child_stack für gewöhnlich auf die oberste Adresse im bereitgehaltenen
Speicherbereich zeigt.
Das untere Byte von flags enthält die Nummer des Signals, das bei
Beendigung des Kindprozesses an den Vaterprozess geschickt werden soll.
flags kann darüber hinaus noch durch bitweises Oder mit den folgenden
Konstanten verknüpft werden. Dadurch wird festgelegt, welche Ressourcen
Vater- und Kindprozess sich teilen.
CLONE_VM
Ist CLONE_VM gesetzt, laufen Vater- und Kindprozess im selben
Adressraum. Insbesondere ist das Resultat von Schreibzugriffen
eines Prozesses in den gemeinsamen Speicher auch vom anderen
Prozess aus sichtbar. Zudem gilt jede Veränderung der
Speichermappings durch mmap(2) oder munmap(2) für beide
Prozesse.
Ist CLONE_VM nicht gesetzt, erhält der Kindprozess seinen
eigenen Adressraum. Wie auch bei fork(2) bleiben Schreibzugriffe
auf den Speicher oder Änderungen am Speichermapping auf den
jeweiligen Prozess beschränkt.
CLONE_FS
Ist CLONE_FS gesetzt, teilen sich Vater- und Kindprozess ihre
Informationen über das Dateisystem. Dazu zählen der Ort des
Wurzelverzeichnisses, das aktuelle Arbeitsverzeichnis und die
Maske der Dateizugriffsrechte. Jeder Aufruf von chroot(2),
chdir(2) oder umask(2) durch entweder den Vater- oder den
Kindprozess beeinflusst auch die Informationen des jeweils
anderen Prozesses.
Ist CLONE_FS nicht gesetzt, erhält der Kindprozess von __clone
eine Kopie der Dateisysteminformationen. Aufrufe von chroot(2),
chdir(2) und umask(2) beeinflussen daraufhin lediglich einen der
beiden Prozesse.
CLONE_FILES
Ist CLONE_FILES gesetzt, teilen sich Vater- und Kindprozess ihre
Dateideskriptoren. Sie verweisen stets auf dieselbe Datei,
sowohl im Vater-, als auch im Kindprozess. Jeder Deskriptor, der
in einem der beiden Prozesse erzeugt wird, ist auch im anderen
Prozess gültig. Ebenso wirkt sich das Schließen eines
Deskriptors oder das Ändern der Attribute auf beide Prozesse
zugleich aus.
Ist CLONE_FILES nicht gesetzt, erhält der Kindprozess durch
__clone eine Kopie der aktuell geöffneten Dateideskriptoren.
Alle anschließend durchgeführten Operationen auf die
Deskriptoren bleiben auf den jeweiligen Prozess beschränkt.
CLONE_SIGHAND
Ist CLONE_SIGHAND gesetzt, teilen sich Vater- und Kindprozess
die Tabelle der Signalhandler. Ruft einer der beiden Prozesse
sigaction(2) auf, um das Antwortverhalten auf ein Signal zu
verändern, so betrifft dies auch den anderen Prozess. Jedoch
besitzen Vater- und Kindprozess nach wie vor getrennte
Signalmasken und getrennte Listen der noch unbearbeiteten
Signale. Einzelne Signale können daher durch Aufruf von
sigprocmask(2) lokal für einen Prozess geblockt oder zugelassen
werden.
Ist CLONE_SIGHAND nicht gesetzt, erhält der Kindprozess durch
den __clone-Aufruf eine Kopie des Signalhandlers. Ein
nachfolgendes sigaction(2) betrifft dann nur noch den
aufrufenden Prozess.
CLONE_PID
Ist CLONE_PID gesetzt, erhält der Kindprozess dieselbe
Prozesskennung wie der Vaterprozess.
Ist CLONE_PID nicht gesetzt, erhält der Kindprozess eine eigene
Prozesskennung, unabhängig von der Kennung des Vaterprozesses.
RÜCKGABEWERT
Ist __clone erfolgreich, wird im Vaterprozess die Prozesskennung des
Kindprozesses zurückgegeben. Im Kindprozess wird 0 zurückgeliefert. Im
Fehlerfall wird -1 zurückgegeben, es wird kein Kindprozess erzeugt, und
errno wird entsprechend der Fehlerursache gesetzt.
FEHLER
EAGAIN Augenblicklich laufen zu viele andere Prozesse.
ENOMEM __clone ist nicht in der Lage, ausreichend viel Speicher
anzufordern für die Verwaltungsstrukturen des Kindprozesses oder
für die zu kopierenden Bereiche aus der Vaterumgebung.
BUGS
Ab Kernelversion 2.1.97 sollte CLONE_PID nicht mehr verwendet werden,
da Teile des Betriebssystems und der Großteil der Systemprogramme von
eindeutigen Prozesskennungen ausgehen.
Version 5 der libc kennt keinen __clone-Aufruf. Die Nachfolgerversion
libc6 (auch glibc2 genannt) stellt __clone in der hier beschriebenen
Form zur Verfügung.
KONFORM ZU
Der __clone-Aufruf ist Linux-spezifisch und sollte nicht in als
portabel geltenden Programmen eingesetzt werden. Um Programme auf
Thread-Basis zu entwickeln, sollte statt dessen auf
Bibliotheksfunktionen zurückgegriffen werden, die eine POSIX-1003.1c-
konforme Programmierschnittstelle bereitstellen. Dazu zählen die in
libc6/glibc2 enthaltenen LinuxThreads. Siehe pthread_create(3thr).
Diese Dokumentation basiert auf den Kernelversionen 2.0.x und 2.1.x
sowie glibc 2.0.x.
SIEHE AUCH
fork(2), pthread_create(3thr)