1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224
|
.\" Hey Emacs! This file is -*- nroff -*- source.
.\"
.\" Copyright (c) 1992 Drew Eckhardt <drew@cs.colorado.edu>, March 28, 1992
.\" May be distributed under the GNU General Public License.
.\" Modified by Michael Haardt <michael@moria.de>
.\" Modified Sat Jul 24 13:22:07 1993 by Rik Faith <faith@cs.unc.edu>
.\" Modified 21 Aug 1994 by Michael Chastain <mec@shell.portal.com>:
.\" New man page (copied from 'fork.2').
.\" Modified 10 June 1995 by Andries Brouwer <aeb@cwi.nl>
.\" Modified 25 april 1998 by Xavier Leroy <Xavier.Leroy@inria.fr>
.\" Translated into german by Daniel Kobras (kobras@linux.de)
.\"
.TH CLONE 2 "23. Januar 2001" "Linux 2.0.33" "Systemaufrufe"
.SH BEZEICHNUNG
__clone \- Erzeugt einen Kindprozess
.SH "ÜBERSICHT"
.B #include <sched.h>
.sp
.BI "int __clone(int (*" "fn" ") (void *" "arg" "), void *" "child_stack" ", int " "flags" ", void *" "arg" ")"
.SH BESCHREIBUNG
.B __clone
erzeugt einen neuen Prozess, ähnlich wie
.BR fork (2)
dies tut. Im Gegensatz zu
.BR fork (2)
erlaubt es
.B __clone
jedoch, dass der Kindprozess Teile seines Kontextes mit dem Vaterprozess teilt.
Dazu zählen Speicherbereiche, die verwendeten Dateideskriptoren oder
Signalhandler.
.B __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.
.PP
Wird ein Kindprozess erzeugt, führt er das Funktionsprogramm
.IR fn ( arg )
aus. Das Argument
.I fn
zeigt auf eine Funktion, die vom Kindprozess zu Beginn seiner Ausführung
abgearbeitet wird.
.I arg
wird dieser Funktion als Argument übergeben.
.PP
Kehrt die Funktion
.IR fn ( arg )
zurück, so beendet sich auch der gesamte Kindprozess. Der Ganzzahlwert,
der von
.I fn
zurückgeliefert wird, entspricht dem Exit-Code des Kindprozesses. Der
Kindprozess kann auch durch ein explizites
.BR exit (1)
oder durch ein geeignetes Signal beendet werden.
.PP
Das Argument
.I 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
.B __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
.I child_stack
für gewöhnlich auf die oberste Adresse im bereitgehaltenen Speicherbereich
zeigt.
.PP
Das untere Byte von
.I flags
enthält die Nummer des Signals, das bei Beendigung des Kindprozesses an
den Vaterprozess geschickt werden soll.
.I 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.
.PP
.TP
.B CLONE_VM
Ist
.B 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
.BR mmap (2)
oder
.BR munmap (2)
für beide Prozesse.
Ist
.B CLONE_VM
nicht gesetzt, erhält der Kindprozess seinen eigenen Adressraum. Wie auch bei
.BR fork (2)
bleiben Schreibzugriffe auf den Speicher oder Änderungen am Speichermapping
auf den jeweiligen Prozess beschränkt.
.PP
.TP
.B CLONE_FS
Ist
.B 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
.BR chroot (2),
.BR chdir (2)
oder
.BR umask (2)
durch entweder den Vater- oder den Kindprozess beeinflusst auch die
Informationen des jeweils anderen Prozesses.
Ist
.B CLONE_FS
nicht gesetzt, erhält der Kindprozess von
.B __clone
eine Kopie der Dateisysteminformationen. Aufrufe von
.BR chroot (2),
.BR chdir (2)
und
.BR umask (2)
beeinflussen daraufhin lediglich einen der beiden Prozesse.
.PP
.TP
.B CLONE_FILES
Ist
.B 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
.B CLONE_FILES
nicht gesetzt, erhält der Kindprozess durch
.B __clone
eine Kopie der aktuell geöffneten Dateideskriptoren. Alle anschließend
durchgeführten Operationen auf die Deskriptoren bleiben auf den jeweiligen
Prozess beschränkt.
.PP
.TP
.B CLONE_SIGHAND
Ist
.B CLONE_SIGHAND
gesetzt, teilen sich Vater- und Kindprozess die Tabelle der Signalhandler.
Ruft einer der beiden Prozesse
.BR 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
.BR sigprocmask (2)
lokal für einen Prozess geblockt oder zugelassen werden.
Ist
.B CLONE_SIGHAND
nicht gesetzt, erhält der Kindprozess durch den
.BR __clone -Aufruf
eine Kopie des Signalhandlers. Ein nachfolgendes
.BR sigaction (2)
betrifft dann nur noch den aufrufenden Prozess.
.PP
.TP
.B CLONE_PID
Ist
.B CLONE_PID
gesetzt, erhält der Kindprozess dieselbe Prozesskennung wie der Vaterprozess.
Ist
.B CLONE_PID
nicht gesetzt, erhält der Kindprozess eine eigene Prozesskennung, unabhängig
von der Kennung des Vaterprozesses.
.PP
.SH "RÜCKGABEWERT"
Ist
.B __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
.I errno
wird entsprechend der Fehlerursache gesetzt.
.PP
.SH FEHLER
.TP
.B EAGAIN
Augenblicklich laufen zu viele andere Prozesse.
.TP
.B ENOMEM
.B __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.
.PP
.SH BUGS
Ab Kernelversion 2.1.97 sollte
.B CLONE_PID
nicht mehr verwendet werden, da Teile des Betriebssystems und der Großteil
der Systemprogramme von eindeutigen Prozesskennungen ausgehen.
.PP
Version 5 der libc kennt keinen
.BR __clone -Aufruf.
Die Nachfolgerversion libc6 (auch glibc2 genannt) stellt
.B __clone
in der hier beschriebenen Form zur Verfügung.
.PP
.SH "KONFORM ZU"
Der
.BR __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
.BR pthread_create (3thr).
.PP
Diese Dokumentation basiert auf den Kernelversionen 2.0.x und 2.1.x sowie
glibc 2.0.x.
.SH "SIEHE AUCH"
.BR fork (2),
.BR pthread_create (3thr)
|