¿Se copian los hilos al llamar a fork?

Si tengo un programa que se ejecuta con hilos y llamo fork()en un sistema basado en Unix, ¿se copian los hilos? Sé que la memoria virtual para el proceso actual se copia 1: 1 al nuevo proceso generado. Sé que los hilos tienen su propia pila en la memoria virtual de un proceso. Por lo tanto, al menos la pila de hilos también debe copiarse. Sin embargo, no sé si hay algo más en los subprocesos que no reside en la memoria virtual y, por lo tanto, NO se copia. Si no lo hay, ¿los dos procesos comparten los hilos o son copias independientes?

No.

Los hilos no se copian fork(). La especificación POSIX dice (el énfasis es mío):

fork - crea un nuevo proceso

Se creará un proceso con un solo hilo . Si un proceso de subprocesos múltiples llama a fork (), el nuevo proceso contendrá una réplica del subproceso de llamada y su espacio de direcciones completo, posiblemente incluyendo los estados de mutexes y otros recursos. En consecuencia, para evitar errores, el proceso secundario solo puede ejecutar operaciones seguras de señal asíncrona hasta el momento en que se llame a una de las funciones ejecutivas.

Para evitar este problema, existe una pthread_atfork()función para ayudar.

tenedor hombre :

El proceso hijo se crea con un solo hilo, el que se llama fork (). Todo el espacio de direcciones virtuales del padre se replica en el hijo, incluidos los estados de mutexes, variables de condición y otros objetos pthreads; El uso de pthread_atfork (3) puede ser útil para tratar los problemas que esto puede causar.

De The Open Group Base Especificaciones Número 7, horquilla de la edición 2018 :

Se creará un proceso con un solo hilo. Si un proceso de subprocesos múltiples llama a fork () , el nuevo proceso contendrá una réplica del hilo de llamada y su espacio de direcciones completo, posiblemente incluyendo los estados de mutexes y otros recursos. En consecuencia, para evitar errores, el proceso hijo solo puede ejecutar operaciones seguras de señal asíncrona hasta el momento en que se llame a una de las funciones ejecutivas .

Cuando la aplicación llama a fork () desde un controlador de señal y cualquiera de los controladores de fork registrados por pthread_atfork () llama a una función que no es segura para la señal asíncrona, el comportamiento es indefinido.

Originalmente, la "bifurcación" se lograba escribiendo la tarea en el disco y luego, en lugar de leer en un hilo diferente (lo que se haría si se intercambia la tarea por una diferente), modificando el ID de la tarea de la imagen que aún está en la memoria y continuando con su ejecución (como la nueva tarea). Esta fue una modificación muy simple al mecanismo básico de cambio de tareas, donde solo una tarea ocuparía la memoria RAM a la vez.

Por supuesto, a medida que la gestión de la memoria se hizo más elaborada, este esquema se modificó para adaptarse al nuevo entorno.