git.infodrom.org Git - infodrom/manpages-de/blob - man2/clone.2

   1 .\" Hey Emacs! This file is -*- nroff -*- source.
   2 .\"
   3 .\" Copyright (c) 1992 Drew Eckhardt <drew@cs.colorado.edu>, March 28, 1992
   4 .\" May be distributed under the GNU General Public License.
   5 .\" Modified by Michael Haardt <michael@moria.de>
   6 .\" Modified Sat Jul 24 13:22:07 1993 by Rik Faith <faith@cs.unc.edu>
   7 .\" Modified 21 Aug 1994 by Michael Chastain <mec@shell.portal.com>:
   8 .\"   New man page (copied from 'fork.2').
   9 .\" Modified 10 June 1995 by Andries Brouwer <aeb@cwi.nl>
  10 .\" Modified 25 april 1998 by Xavier Leroy <Xavier.Leroy@inria.fr>
  11 .\" Translated into german by Daniel Kobras (kobras@linux.de)
  12 .\"
  13 .TH CLONE 2 "23. Januar 2001" "Linux 2.0.33" "Systemaufrufe"
  14 .SH BEZEICHNUNG
  15 __clone \- Erzeugt einen Kindprozess
  16 .SH "ÜBERSICHT"
  17 .B #include <sched.h>
  18 .sp
  19 .BI "int __clone(int (*" "fn" ") (void *" "arg" "), void *" "child_stack" ", int " "flags" ", void *" "arg" ")"
  20
  21 .SH BESCHREIBUNG
  22 .B __clone
  23 erzeugt einen neuen Prozess, ähnlich wie
  24 .BR fork (2)
  25 dies tut.  Im Gegensatz zu
  26 .BR fork (2)
  27 erlaubt es
  28 .B __clone
  29 jedoch, dass der Kindprozess Teile seines Kontextes mit dem Vaterprozess teilt.
  30 Dazu zählen Speicherbereiche, die verwendeten Dateideskriptoren oder
  31 Signalhandler.
  32 .B __clone
  33 wird in erster Linie dazu benutzt, um Threads zu implementieren. Das sind
  34 mehrere parallel zueinander ablaufende Programmstränge eines Prozesses in
  35 einem gemeinsamen Speicherbereich.
  36 .PP
  37 Wird ein Kindprozess erzeugt, führt er das Funktionsprogramm
  38 .IR fn ( arg )
  39 aus. Das Argument
  40 .I fn
  41 zeigt auf eine Funktion, die vom Kindprozess zu Beginn seiner Ausführung
  42 abgearbeitet wird.
  43 .I arg
  44 wird dieser Funktion als Argument übergeben.
  45 .PP
  46 Kehrt die Funktion
  47 .IR fn ( arg )
  48 zurück, so beendet sich auch der gesamte Kindprozess. Der Ganzzahlwert,
  49 der von
  50 .I fn
  51 zurückgeliefert wird, entspricht dem Exit-Code des Kindprozesses. Der
  52 Kindprozess kann auch durch ein explizites
  53 .BR exit (1)
  54 oder durch ein geeignetes Signal beendet werden.
  55 .PP
  56 Das Argument
  57 .I child_stack
  58 bestimmt den Ort des Stapelspeichers, der vom Kindprozess verwendet wird.
  59 Da Vater- und Kindprozess sich Speicherbereiche teilen können, ist es im
  60 allgemeinen nicht möglich, beide auf demselben Stapelspeicher ablaufen
  61 zu lassen. Der Vaterprozess muss daher einen Speicherbereich als
  62 Stapelspeicher für den Kindprozess bereithalten und einen Zeiger darauf via
  63 .B __clone
  64 an den Kindprozess übergeben. Mit Ausnahme von HP PA-Maschinen wächst der
  65 Stapelspeicher auf allen von Linux unterstützten Prozessoren nach unten,
  66 so dass
  67 .I child_stack
  68 für gewöhnlich auf die oberste Adresse im bereitgehaltenen Speicherbereich
  69 zeigt.
  70 .PP
  71 Das untere Byte von
  72 .I flags
  73 enthält die Nummer des Signals, das bei Beendigung des Kindprozesses an
  74 den Vaterprozess geschickt werden soll.
  75 .I flags
  76 kann darüber hinaus noch durch bitweises Oder mit den folgenden Konstanten
  77 verknüpft werden. Dadurch wird festgelegt, welche Ressourcen Vater- und
  78 Kindprozess sich teilen.
  79 .PP
  80 .TP
  81 .B CLONE_VM
  82 Ist
  83 .B CLONE_VM
  84 gesetzt, laufen Vater- und Kindprozess im selben Adressraum. Insbesondere
  85 ist das Resultat von Schreibzugriffen eines Prozesses in den gemeinsamen
  86 Speicher auch vom anderen Prozess aus sichtbar. Zudem gilt jede
  87 Veränderung der Speichermappings durch
  88 .BR mmap (2)
  89 oder
  90 .BR munmap (2)
  91 für beide Prozesse.
  92
  93 Ist
  94 .B CLONE_VM
  95 nicht gesetzt, erhält der Kindprozess seinen eigenen Adressraum. Wie auch bei
  96 .BR fork (2)
  97 bleiben Schreibzugriffe auf den Speicher oder Änderungen am Speichermapping
  98 auf den jeweiligen Prozess beschränkt.
  99 .PP
 100 .TP
 101 .B CLONE_FS
 102 Ist
 103 .B CLONE_FS
 104 gesetzt, teilen sich Vater- und Kindprozess ihre Informationen über das
 105 Dateisystem. Dazu zählen der Ort des Wurzelverzeichnisses, das aktuelle
 106 Arbeitsverzeichnis und die Maske der Dateizugriffsrechte. Jeder Aufruf von
 107 .BR chroot (2),
 108 .BR chdir (2)
 109 oder
 110 .BR umask (2)
 111 durch entweder den Vater- oder den Kindprozess beeinflusst auch die
 112 Informationen des jeweils anderen Prozesses.
 113
 114 Ist
 115 .B CLONE_FS
 116 nicht gesetzt, erhält der Kindprozess von
 117 .B __clone
 118 eine Kopie der Dateisysteminformationen. Aufrufe von
 119 .BR chroot (2),
 120 .BR chdir (2)
 121 und
 122 .BR umask (2)
 123 beeinflussen daraufhin lediglich einen der beiden Prozesse.
 124 .PP
 125 .TP
 126 .B CLONE_FILES
 127 Ist
 128 .B CLONE_FILES
 129 gesetzt, teilen sich Vater- und Kindprozess ihre Dateideskriptoren. Sie
 130 verweisen stets auf dieselbe Datei, sowohl im Vater-, als auch im
 131 Kindprozess. Jeder Deskriptor, der in einem der beiden Prozesse erzeugt
 132 wird, ist auch im anderen Prozess gültig. Ebenso wirkt sich das Schließen
 133 eines Deskriptors oder das Ändern der Attribute auf beide Prozesse
 134 zugleich aus.
 135
 136 Ist
 137 .B CLONE_FILES
 138 nicht gesetzt, erhält der Kindprozess durch
 139 .B __clone
 140 eine Kopie der aktuell geöffneten Dateideskriptoren. Alle anschließend
 141 durchgeführten Operationen auf die Deskriptoren bleiben auf den jeweiligen
 142 Prozess beschränkt.
 143 .PP
 144 .TP
 145 .B CLONE_SIGHAND
 146 Ist
 147 .B CLONE_SIGHAND
 148 gesetzt, teilen sich Vater- und Kindprozess die Tabelle der Signalhandler.
 149 Ruft einer der beiden Prozesse
 150 .BR sigaction (2)
 151 auf, um das Antwortverhalten auf ein Signal zu verändern, so betrifft dies
 152 auch den anderen Prozess. Jedoch besitzen Vater- und Kindprozess nach wie vor
 153 getrennte Signalmasken und getrennte Listen der noch unbearbeiteten Signale.
 154 Einzelne Signale können daher durch Aufruf von
 155 .BR sigprocmask (2)
 156 lokal für einen Prozess geblockt oder zugelassen werden.
 157
 158 Ist
 159 .B CLONE_SIGHAND
 160 nicht gesetzt, erhält der Kindprozess durch den
 161 .BR __clone -Aufruf
 162 eine Kopie des Signalhandlers. Ein nachfolgendes
 163 .BR sigaction (2)
 164 betrifft dann nur noch den aufrufenden Prozess.
 165 .PP
 166 .TP
 167 .B CLONE_PID
 168 Ist
 169 .B CLONE_PID
 170 gesetzt, erhält der Kindprozess dieselbe Prozesskennung wie der Vaterprozess.
 171
 172 Ist
 173 .B CLONE_PID
 174 nicht gesetzt, erhält der Kindprozess eine eigene Prozesskennung, unabhängig
 175 von der Kennung des Vaterprozesses.
 176 .PP
 177 .SH "RÜCKGABEWERT"
 178 Ist
 179 .B __clone
 180 erfolgreich, wird im Vaterprozess die Prozesskennung des Kindprozesses
 181 zurückgegeben. Im Kindprozess wird 0 zurückgeliefert. Im Fehlerfall wird
 182 \-1 zurückgegeben, es wird kein Kindprozess
 183 erzeugt, und
 184 .I errno
 185 wird entsprechend der Fehlerursache gesetzt.
 186 .PP
 187 .SH FEHLER
 188 .TP
 189 .B EAGAIN
 190 Augenblicklich laufen zu viele andere Prozesse.
 191 .TP
 192 .B ENOMEM
 193 .B __clone
 194 ist nicht in der Lage, ausreichend viel Speicher anzufordern
 195 für die Verwaltungsstrukturen des Kindprozesses oder für die zu kopierenden
 196 Bereiche aus der Vaterumgebung.
 197 .PP
 198 .SH BUGS
 199 Ab Kernelversion 2.1.97 sollte
 200 .B CLONE_PID
 201 nicht mehr verwendet werden, da Teile des Betriebssystems und der Großteil
 202 der Systemprogramme von eindeutigen Prozesskennungen ausgehen.
 203 .PP
 204 Version 5 der libc kennt keinen
 205 .BR __clone -Aufruf.
 206 Die Nachfolgerversion libc6 (auch glibc2 genannt) stellt
 207 .B __clone
 208 in der hier beschriebenen Form zur Verfügung.
 209 .PP
 210 .SH "KONFORM ZU"
 211 Der
 212 .BR __clone -Aufruf
 213 ist Linux-spezifisch und sollte nicht in als portabel geltenden Programmen
 214 eingesetzt werden. Um Programme auf Thread-Basis zu entwickeln, sollte statt
 215 dessen auf Bibliotheksfunktionen zurückgegriffen werden, die eine
 216 POSIX-1003.1c-konforme Programmierschnittstelle bereitstellen. Dazu zählen
 217 die in libc6/glibc2 enthaltenen LinuxThreads. Siehe
 218 .BR pthread_create (3thr).
 219 .PP
 220 Diese Dokumentation basiert auf den Kernelversionen 2.0.x und 2.1.x sowie
 221 glibc 2.0.x.
 222 .SH "SIEHE AUCH"
 223 .BR fork (2),
 224 .BR pthread_create (3thr)