¿Por qué un programa con fork () a veces imprime su salida varias veces?

En el Programa 1 Hello worldse imprime solo una vez, pero cuando lo elimino \ny lo ejecuto (Programa 2), la salida se imprime 8 veces. ¿Alguien puede explicarme el significado de \naquí y cómo afecta al fork()?

Programa 1

#include <sys/types.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

int main()
{
    printf("hello world...\n");
    fork();
    fork();
    fork();
}

Salida 1:

hello world... 

Programa 2

#include <sys/types.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

int main()
{
    printf("hello world...");
    fork();
    fork();
    fork();
}

Salida 2:

hello world... hello world...hello world...hello world...hello world...hello world...hello world...hello world...

Cuando se envía a la salida estándar utilizando la printf()función de la biblioteca C , la salida generalmente se almacena en búfer. El búfer no se vacía hasta que fflush(stdout)salga una nueva línea, llame o salga del programa ( _exit()aunque no mediante una llamada ). El flujo de salida estándar se almacena de manera predeterminada en línea de esta manera cuando está conectado a un TTY.

Cuando se bifurca el proceso en el "Programa 2", los procesos secundarios heredan cada parte del proceso principal, incluido el búfer de salida no vaciado. Esto copia efectivamente el búfer no vaciado a cada proceso secundario.

Cuando finaliza el proceso, las memorias intermedias se vacían. Comienza un gran total de ocho procesos (incluido el proceso original), y el búfer no vaciado se vaciará al finalizar cada proceso individual.

Es ocho porque en cada fork()uno obtienes el doble del número de procesos que tenías antes fork()(ya que son incondicionales), y tienes tres de estos (2 ³ = 8).

No afecta el tenedor de ninguna manera.

En el primer caso, terminas con 8 procesos sin nada que escribir, porque el búfer de salida ya estaba vacío (debido a \n).

En el segundo caso, todavía tiene 8 procesos, cada uno con un búfer que contiene "Hola mundo ..." y el búfer se escribe al final del proceso.

@Kusalananda explicó por qué se repite la salida . Si tiene curiosidad por qué la salida se repite 8 veces y no solo 4 veces (el programa base + 3 bifurcaciones):

int main()
{
    printf("hello world...");
    fork(); // here it creates a copy of itself --> 2 instances
    fork(); // each of the 2 instances creates another copy of itself --> 4 instances
    fork(); // each of the 4 instances creates another copy of itself --> 8 instances
}

El trasfondo importante aquí es que stdoutse requiere que el estándar proteja la línea como configuración predeterminada.

Esto hace que \na vacíe la salida.

Como el segundo ejemplo no contiene la nueva línea, la salida no se vacía y, como fork()copia todo el proceso, también copia el estado del stdoutbúfer.

Ahora, estas fork()llamadas en su ejemplo crean 8 procesos en total, todos ellos con una copia del estado del stdoutbúfer.

Por definición, todos estos procesos llaman exit()cuando regresan main()y exit()llamadas fflush()seguidas de fclose()todas las secuencias stdio activas . Esto incluye stdouty, como resultado, ve el mismo contenido ocho veces.

Es una buena práctica llamar fflush()a todas las secuencias con salida pendiente antes de llamar fork()o dejar que la llamada secundaria bifurcada explícitamente _exit()solo salga del proceso sin vaciar las secuencias stdio.

Tenga en cuenta que las llamadas exec()no eliminan las memorias intermedias estándar, por lo que está bien no preocuparse por las memorias intermedias si usted (después de llamar fork()) llama exec()y (si eso falla) _exit().

Por cierto: para comprender que el almacenamiento en búfer incorrecto puede causar, aquí hay un error anterior en Linux que se ha solucionado recientemente:

El estándar requiere stderrque no stderresté almacenado en búfer de manera predeterminada, pero Linux lo ignoró e hizo que la línea esté en búfer y (aún peor) esté completamente en búfer en caso de que stderr fuera redirigido a través de una tubería. Entonces, los programas escritos para UNIX produjeron cosas sin nueva línea demasiado tarde en Linux.

Vea el comentario a continuación, parece estar solucionado ahora.

Esto es lo que hago para solucionar este problema de Linux:

    /* 
     * Linux comes with a broken libc that makes "stderr" buffered even 
     * though POSIX requires "stderr" to be never "fully buffered". 
     * As a result, we would get garbled output once our fork()d child 
     * calls exit(). We work around the Linux bug by calling fflush() 
     * before fork()ing. 
     */ 
    fflush(stderr); 

Este código no daña en otras plataformas, ya que llamar fflush()a una transmisión que se acaba de vaciar es un noop.