Provided by:
manpages-es_1.55-10_all 
NOMBRE
clone - crea un proceso hijo
SINOPSIS
#include <sched.h>
int clone(int (*fn)(void *), void *child_stack, int flags, void *arg);
_syscall2(int, clone, int, flags, void *, child_stack)
DESCRIPCI'ON
clone crea un nuevo proceso como lo hace fork(2). clone es una funcion
de biblioteca situada encima de la llamada al sistema subyacente clone
, de aqui en adelante referida como sys_clone. Una descripcion de
sys_clone se da hacia el final de esta pagina.
A diferencia de fork(2), estas llamadas permiten al proceso hijo
compartir partes de su contexto de ejecucion con el proceso invocador,
tales como el espacio de memoria, la tabla de descriptores de fichero y
la tabla de manejadores de senal. (Observe que en esta pagina de
manual, "proceso invocador" normalmente se corresponde con "proceso
padre". Vea la descripcion de CLONE_PARENT mas abajo.)
El principal uso de clone es para implementar los hilos: multiples
hilos de control en un programa que se ejecutan concurrentemente en un
espacio de memoria compartido.
Cuando se crea el proceso hijo con clone, este ejecuta la funcion
fn(arg). (Eso difiere de fork(2), en donde la ejecucion continua en el
hijo desde el punto en el que se encuentra la llamada fork(2) El
argumento fn es un puntero a una funcion que es ejecutada por el
proceso hijo al comienzo de su ejecucion. El argumento arg se pasa a
la funcion fn.
Cuando la funcion fn(arg) regresa, el proceso hijo termina. El entero
devuelto por fn es el codigo de salida del proceso hijo. El proceso
hijo tambien puede terminar explicitamente ejecutando exit(2) o despues
de recibir una senal fatal.
El argumento child_stack indica la posicion de la pila utilizada por el
proceso hijo. Puesto que los procesos hijo e invocador pueden compartir
la memoria, no es posible, en general, para el proceso hijo ejecutarse
usando la misma pila que el proceso invocador. Por tanto, el proceso
invocador debe preparar un area de memoria para la pila del hijo y
pasar un puntero a dicha area a clone. Las pilas crecen hacia abajo en
todos los procesadores en los que se ejecuta Linux (excepto en el
procesador HP PA), por lo que child_stack apunta normalmente a la
direccion mas alta de la zona de memoria preparada para la pila del
hijo.
El byte bajo de flags contiene el numero de la senal enviada al padre
cuando el hijo muere. Si la senal especificada es cualquiera distinta
de SIGCHLD, el proceso padre debe especificar las opciones __WALL o
__WCLONE cuando espera al hijo con wait(2). Si no se indica ninguna
senal, el proceso padre no es notificado cuando el hijo termina.
flags puede tambien ser operado con un OR a nivel de bits (bitwise or)
con una o varias de las siguientes constantes, para asi especificar que
van a compartir los procesos invocador e hijo:
CLONE_PARENT
(Linux 2.4 en adelante) Si CLONE_PARENT esta presente, el padre
del nuevo hijo (valor devuelto por getppid(2)) sera el mismo que
el del proceso invocador.
Si CLONE_PARENT no esta presente, (al igual que ocurre con
fork(2)) el padre del hijo es el proceso invocador.
Observe que es el proceso padre, tal como informa getppid(2), el
que es notificado cuando el hijo termina, asi que si se
especifica la opcion CLONE_PARENT , sera notificado el padre del
proceso invocador, en lugar del propio proceso invocador.
CLONE_FS
Si se pone CLONE_FS, los procesos invocador e hijo comparten la
misma informacion del sistema de ficheros. Esta incluye la raiz
del sistema de ficheros, el directorio de trabajo actual y el
valor de umask. Cualquier llamada a chroot(2), chdir(2) o
umask(2) realizada por el proceso invocador o hijo tambien
afecta al otro proceso.
Si no se pone CLONE_FS, el proceso hijo trabaja con una copia de
la informacion del sistema de ficheros del proceso invocador en
el momento de ejecutar la llamada clone. Las llamadas a
chroot(2), chdir(2) o umask(2) realizadas despues por uno de los
procesos no afectan al otro.
CLONE_FILES
Si se pone CLONE_FILES, los procesos invocador e hijo comparten
la misma tabla de descriptores de fichero. Los descriptores de
fichero siempre se refieren a los mismos ficheros en el
invocador y en el proceso hijo. Cualquier descriptor de fichero
creado por el proceso invocador o por el proceso hijo tambien es
valido en el otro proceso. De igual forma, si uno de los
procesos cierra un descriptor de fichero o cambia sus banderas
(flags) asociadas, el otro proceso tambien se vera afectado.
Si no se pone CLONE_FILES, el proceso hijo hereda una copia de
todos los descriptores de fichero abiertos en el proceso
invocador en el momento de ejecutar clone. Las operaciones
sobre los descriptores de fichero realizadas despues por uno de
los procesos invocador o hijo no afectan al otro.
CLONE_NEWNS
(Linux 2.4.19 en adelante) Comienza el hijo en un nuevo espacio
de nombres.
Cada proceso vive en un espacio de nombres. El espacio de
nombres de un proceso viene dado por los datos (el conjunto de
montajes) que describen la jerarquia de ficheros tal como la ve
ese proceso. Despues de una llamada a fork(2) o clone(2) con la
bandera CLONE_NEWNS desactivada, el hijo vive en el mismo
espacio de nombres que el padre. Las llamadas al sistema
mount(2) y umount(2) cambian el espacio de nombres del proceso
invocador, y por tanto afectan a todos los procesos que viven en
el mismo espacio de nombres, pero no a los que estan en un
espacio de nombres diferente.
Tras una llamada a clone(2) con la bandera CLONE_NEWNS activada,
el hijo clonado comienza su ejecucion en un nuevo espacio de
nombres, inicializado con una copia del espacio de nombres del
padre.
Solamente un proceso privilegiado puede indicar la bandera
CLONE_NEWNS. No esta permitido especificar CLONE_NEWNS y
CLONE_FS en la misma llamada a clone.
CLONE_SIGHAND
Si se pone CLONE_SIGHAND, los procesos invocador e hijo
comparten la misma tabla de manejadores de senal. Si el proceso
invocador o hijo llama a sigaction(2) para cambiar el
comportamiento asociado a una senal, el comportamiento tambien
se cambia en el otro proceso. Sin embargo, los procesos
invocador e hijo todavia tienen diferentes mascaras de senales y
conjuntos de senales pendientes. Por tanto, uno de ellos puede
bloquear o desbloquear algunas senales usando sigprocmask(2) sin
afectar al otro proceso.
Si no se pone CLONE_SIGHAND, el proceso hijo hereda una copia de
los manejadores de senal del proceso invocador en el momento de
ejecutar clone. Las llamadas a sigaction(2) realizadas despues
por uno de los procesos no tendran efecto sobre el otro proceso.
CLONE_PTRACE
Si se especifica la opcion CLONE_PTRACE , y el proceso invocador
esta siendo rastreado, tambien se rastrea al hijo (vea
ptrace(2)).
CLONE_VFORK
Si la opcion CLONE_VFORK esta presente, la ejecucion del proceso
invocador se suspende hasta que el hijo libere sus recursos de
memoria virtual mediante una llamada a execve(2) o _exit(2) (al
igual que con vfork(2)).
Si CLONE_VFORK no esta presente tanto el proceso invocador como
el hijo son planificables tras la llamada, y una aplicacion no
deberia confiar en que se ejecuten en un determinado orden.
CLONE_VM
Si CLONE_VM esta presente, el proceso invocador y el proceso
hijo se ejecutan en el mismo espacio de memoria. En particular,
las escrituras en memoria realizadas por el proceso invocador o
el hijo son visibles tambien en el otro proceso. Ademas,
cualquier ubicacion o eliminacion de memoria realizada con
mmap(2) o munmap(2) por el proceso hijo o invocador tambien
afecta al otro proceso.
Si CLONE_VM no esta presente, el proceso hijo se ejecuta en una
copia separada del espacio de memoria del proceso invocador en
el momento de la llamada a clone. Las escrituras en memoria o
las ubicaciones/eliminaciones de ficheros realizadas por uno de
los procesos no afecta al otro, al igual que con fork(2).
CLONE_PID
Si se pone CLONE_PID, se crea el proceso hijo con el mismo
identificador de proceso que el proceso invocador.
Si no se pone CLONE_PID, el proceso hijo posee un identificador
de proceso unico, distinto del identificador del invocador.
Esta bandera solo puede ser especificada por el proceso de
arranque del sistema (PID 0).
CLONE_THREAD
(Linux 2.4 en adelante) Si CLONE_THREAD esta presente, el
proceso hijo se pone en el mismo grupo de hilos que el proceso
invocador.
Si CLONE_THREAD no esta presente, el proceso hijo se pone en su
propio (nuevo) grupo de hilos, cuyo identificador es el mismo
que el identificador de proceso.
(Los grupos de hilos son una caracteristica anadida en Linux 2.4
para soportar la nocion de un conjunto de hilos compartiendo un
solo PID impuesta por los hilos POSIX. En Linux 2.4, las
llamadas a getpid(2) devuelven el identificador de grupo de
hilos del invocador.)
La llamada al sistema sys_clone se corresponde mas estrechamente con
fork(2) en el hecho de que la ejecucion en el proceso hijo continua
desde el punto de la llamada. Asi, sys_clone solamente requiere los
argumentos flags y child_stack , que tienen el mismo significado que
para clone. (Observe que el orden de estos argumentos difiere de
clone.)
Otra diferencia de sys_clone es que el argumento child_stack puede ser
cero, en cuyo caso la semantica de copia-en-escritura (copy-on-write)
asegura que el proceso hijo obtendra copias de las paginas de pila
cuando cualquiera de los dos procesos modifique la pila. En este caso,
para una operacion correcta, deberia especificarse la opcion CLONE_VM.
VALOR DEVUELTO
En caso de exito, se devuelve el PID del hijo en el hilo de ejecucion
del invocador. En caso de fallo, se devuelve -1 en el contexto del
invocador, no se creara ningun proceso hijo y se asignara a la variable
errno un valor apropiado.
ERRORES
EAGAIN Se estan ejecutando ya demasiados procesos.
ENOMEM __clone no puede reservar suficiente memoria para obtener una
estructura de tarea (task structure) para el hijo o para copiar
aquellas partes del contexto del padre que necesitan ser
copiadas.
EINVAL Devuelto por clone cuando se especifica un valor cero para
child_stack.
EINVAL Se especificaron ambas opciones CLONE_FS y CLONE_NEWNS en flags.
EINVAL Se especifico CLONE_THREAD , pero no CLONE_SIGHAND. (Desde
Linux 2.5.35.)
EPERM Se especifico CLONE_PID por un proceso cuyo PID es distinto de
cero.
FALLOS
Desde la version 2.1.97 del nucleo, no se debe usar la bandera
CLONE_PID ya que otras partes del nucleo y la mayoria del software del
sistema todavia asumen que los identificadores de proceso son unicos.
No hay una entrada para clone en la version 5 de libc. libc 6 (o sea,
glibc 2) proporciona una llamada clone tal como la que se ha descrito
en esta pagina de manual.
OBSERVACIONES
Para las versiones del nucleo 2.4.7-2.4.18 la bandera CLONE_THREAD
implica la bandera CLONE_PARENT.
CONFORME A
Las llamadas clone y sys_clone son especificas de Linux y no deberian
usarse en aquellos programas que pretendan se portables. Para programar
aplicaciones con hilos (multiples hilos de control en el mismo espacio
de memoria) es mejor usar una biblioteca que implemente la API de hilos
POSIX 1003.1c, como la biblioteca LinuxThreads (incluida en glibc2).
Vea pthread_create(3).
Esta pagina de manual se corresponde con los nucleos 2.0.x, 2.1.x,
2.2.x, 2.4.x, y con las versiones 2.0.x y 2.1.x de glibc.
V'EASE TAMBI'EN
fork(2), wait(2), pthread_create(3)