Fork (llamada al sistema)

La siguiente variante del programa "¡Hola, mundo!" demuestra el funcionamiento de la llamada al sistema `fork` en el lenguaje de programación C. El programa se divide en dos procesos, cada uno de los cuales decide qué funcionalidad ejecutar en función del valor de retorno de la llamada al sistema `fork`. Se ha omitido el código repetitivo, como las inclusiones de cabecera .

#include <stdio.h> #include <stdlib.h> #include <unistd.h>int main ( void ) { pid_t pid = fork ();if ( pid == -1 ) { perror ( "fork failed" ); return EXIT_FAILURE ; } else if ( pid == 0 ) { printf ( "¡Hola desde el proceso hijo! \n " ); return EXIT_SUCCESS ; } else { int status ; waitpid ( pid , & status , 0 ); } return EXIT_SUCCESS ; }

A continuación se presenta un análisis detallado de este programa.

pid_t pid = fork ();

La primera instrucción de main llama a la función del sistema fork para dividir la ejecución en dos procesos. El valor de retorno de fork se registra en una variable de tipo pid_t , que es el tipo POSIX para los identificadores de proceso (PID).

if ( pid == -1 ) { perror ( "fork failed" ); return EXIT_FAILURE ; }

El signo menos uno indica un error en fork : no se creó ningún proceso nuevo, por lo que se imprime un mensaje de error.

Si la operación fork se realiza correctamente, entonces existen dos procesos, ambos ejecutando la función principal desde el punto donde fork finalizó. Para que los procesos realicen tareas diferentes, el programa debe bifurcarse según el valor de retorno de fork para determinar si se ejecuta como el proceso hijo o el proceso padre .

else if ( pid == 0 ) { printf ( "¡Hola desde el proceso hijo! \n " ); return EXIT_SUCCESS ; }

En el proceso hijo, el valor de retorno es cero (lo que indica un identificador de proceso no válido ). El proceso hijo imprime el mensaje de saludo deseado y finaliza. (Por razones técnicas, se debe usar la función _exit de POSIX en lugar de la función exit estándar de C ).

else { int status ; waitpid ( pid , & status , 0 ); }

El otro proceso, el padre, recibe de `fork` el identificador del proceso hijo, que siempre es un número positivo. El proceso padre pasa este identificador a la llamada al sistema `waitpid` para suspender la ejecución hasta que el hijo finalice. Cuando esto ocurre, el padre reanuda la ejecución y finaliza mediante la instrucción `return` .

El proceso hijo comienza con una copia de los descriptores de archivo de su padre . ^{[ 6 ]} Para la comunicación entre procesos con intercambio de datos y sincronización entre procesos padre e hijo, se pueden usar tuberías . ^{[ 7 ]} El proceso padre a menudo creará una o varias tuberías, y luego, después de la bifurcación, los procesos cerrarán los extremos de las tuberías que no necesiten. ^{[ 7 ]} Para compartir la misma variable entre los procesos padre e hijo, se debe usar el mapeo de memoria o la memoria compartida . ^{[ 8 ]}

Vfork es una variante de fork con la misma convención de llamada y una semántica muy similar, pero solo debe usarse en situaciones restringidas. Se originó en la versión 3BSD de Unix, ^{[ 9 ] [ 10 ] [ 11 ]} la primera Unix en admitir memoria virtual. Fue estandarizada por POSIX, lo que permitió que vfork tuviera exactamente el mismo comportamiento que fork, pero fue marcada como obsoleta en la edición de 2004 ^{[ 12 ]} y fue reemplazada por posix_spawn () (que normalmente se implementa a través de vfork) en ediciones posteriores.

Cuando se emite una llamada al sistema vfork, el proceso padre se suspenderá hasta que el proceso hijo haya completado su ejecución o haya sido reemplazado con una nueva imagen ejecutable a través de una de las llamadas al sistema de la familia " exec ". El hijo toma prestada la configuración de la unidad de administración de memoria del padre y las páginas de memoria se comparten entre el proceso padre e hijo sin realizar copias, y en particular sin semántica de copia en escritura ; ^{[ 12 ]} por lo tanto, si el proceso hijo realiza una modificación en cualquiera de las páginas compartidas, no se creará una nueva página y las páginas modificadas también serán visibles para el proceso padre. Dado que no hay absolutamente ninguna copia de página involucrada (consumiendo memoria adicional), esta técnica es una optimización sobre el fork simple en entornos de copia completa cuando se usa con exec. En POSIX, usar vfork para cualquier propósito que no sea como preludio a una llamada inmediata a una función de la familia exec (y algunas otras operaciones selectas) da lugar a un comportamiento indefinido . ^{[ 12 ]} Al igual que con vfork, el hijo toma prestadas estructuras de datos en lugar de copiarlas. vfork sigue siendo más rápido que un fork que utiliza semántica de copia en escritura.

El sistema V no admitía esta llamada a función antes de la introducción del sistema VR4, porque el uso compartido de memoria que provoca es propenso a errores:

Vfork no copia las tablas de páginas, por lo que es más rápido que la implementación de fork de System V. Sin embargo, el proceso hijo se ejecuta en el mismo espacio de direcciones físicas que el proceso padre (hasta que se ejecuta exec o exit ) y, por lo tanto, puede sobrescribir los datos y la pila del padre. Podría surgir una situación peligrosa si un programador usa vfork incorrectamente, por lo que la responsabilidad de llamar a vfork recae en el programador. La diferencia entre el enfoque de System V y el de BSD es filosófica: ¿Debería el kernel ocultar las peculiaridades de su implementación a los usuarios, o debería permitir a los usuarios avanzados la oportunidad de aprovechar la implementación para realizar una función lógica de manera más eficiente?

De manera similar, la página man de Linux para vfork desaconseja encarecidamente su uso: ^{[ 9 ]}

Resulta bastante lamentable que Linux haya revivido este fantasma del pasado. La página man de BSD indica: "Esta llamada al sistema se eliminará cuando se implementen mecanismos adecuados de compartición de memoria. Los usuarios no deben depender de la semántica de compartición de memoria de vfork(), ya que, en ese caso, se convertirá en sinónimo de fork(2)".

Otros problemas con vfork incluyen interbloqueos que podrían ocurrir en programas multihilo debido a interacciones con el enlace dinámico . ^{[ 14 ]} Como reemplazo de la interfaz vfork , POSIX introdujo la familia de funciones posix_spawn que combinan las acciones de fork y exec. Estas funciones pueden implementarse como rutinas de biblioteca en términos de fork , como se hace en Linux, ^{[ 14 ]} o en términos de vfork para un mejor rendimiento, como se hace en Solaris, ^{[ 14 ] [ 15 ]} pero la especificación POSIX señala que fueron "diseñadas como operaciones del kernel ", especialmente para sistemas operativos que se ejecutan en hardware restringido y sistemas en tiempo real . ^{[ 16 ]}

Si bien la implementación de 4.4BSD eliminó la implementación de vfork, lo que provocó que vfork tuviera el mismo comportamiento que fork, posteriormente se reinstauró en el sistema operativo NetBSD por razones de rendimiento. ^{[ 10 ]}

Algunos sistemas operativos embebidos, como uClinux, omiten la función fork y solo implementan vfork, porque necesitan operar en dispositivos donde la copia en escritura es imposible de implementar debido a la falta de una unidad de gestión de memoria.

El sistema operativo Plan 9 , creado por los diseñadores de Unix, incluye fork como una variante de una nueva función llamada "rfork" que permite compartir recursos de forma granular entre procesos padre e hijo, incluyendo el espacio de direcciones (excepto un segmento de pila , que es único para cada proceso), variables de entorno y el espacio de nombres del sistema de archivos; ^{[ 17 ]} esto lo convierte en una interfaz unificada para la creación tanto de procesos como de hilos dentro de ellos. ^{[ 18 ]} Tanto FreeBSD ^{[ 19 ]} como IRIX adoptaron la llamada al sistema rfork de Plan 9, este último renombrándola como "sproc". ^{[ 20 ]}

clonees una llamada al sistema en el kernel de Linux que crea un proceso hijo que puede compartir partes de su contexto de ejecución con el padre. Al igual que rfork de FreeBSD y sproc de IRIX, clone de Linux se inspiró en rfork de Plan 9 y puede usarse para implementar hilos (aunque los programadores de aplicaciones normalmente usarán una interfaz de nivel superior como pthreads , implementada sobre clone). La característica de "pilas separadas" de Plan 9 e IRIX se ha omitido porque (según Linus Torvalds ) causa demasiada sobrecarga. ^{[ 20 ]}