Por que um programa com fork () às vezes imprime sua saída várias vezes?

No Programa 1, Hello worldé impresso apenas uma vez, mas quando eu removo \ne o executo (Programa 2), a saída é impressa 8 vezes. Alguém pode me explicar o significado \ndaqui e como isso afeta o 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();
}

Saída 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();
}

Saída 2:

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

Ao produzir para a saída padrão usando a printf()função da biblioteca C , a saída geralmente é armazenada em buffer. O buffer não é liberado até você emitir uma nova linha, chamar fflush(stdout)ou sair do programa ( _exit()embora não seja através da chamada ). O fluxo de saída padrão é, por padrão, armazenado em buffer de linha desta maneira quando conectado a um TTY.

Quando você bifurca o processo no "Programa 2", os processos filhos herdam todas as partes do processo pai, incluindo o buffer de saída não liberado. Isso efetivamente copia o buffer não liberado para cada processo filho.

Quando o processo termina, os buffers são liberados. Você inicia um total geral de oito processos (incluindo o processo original) e o buffer não liberado será liberado no final de cada processo individual.

São oito, porque em cada um fork()você obtém o dobro do número de processos que tinha antes fork()(já que são incondicionais), e você tem três deles (2 ³ = 8).

Não afeta o garfo de forma alguma.

No primeiro caso, você acaba com 8 processos sem nada para gravar, porque o buffer de saída já estava esvaziado (devido ao \n).

No segundo caso, você ainda possui 8 processos, cada um com um buffer contendo "Hello world ..." e o buffer é gravado no final do processo.

@Kusalananda explicou por que a saída é repetido . Se você está curioso para saber por que a saída é repetida 8 vezes e não apenas 4 vezes (o programa base + 3 garfos):

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
}

O pano de fundo importante aqui é que stdouté necessário que a linha seja armazenada em buffer pelo padrão como configuração padrão.

Isso faz com que \na descarga da saída.

Como o segundo exemplo não contém a nova linha, a saída não é liberada e, como fork()copia todo o processo, também copia o estado do stdoutbuffer.

Agora, essas fork()chamadas no seu exemplo criam 8 processos no total - todos com uma cópia do estado do stdoutbuffer.

Por definição, todos esses processos são chamados exit()ao retornar main()e exit()chamadas fflush()seguidos fclose()em todos os fluxos de stdio ativos . Isso inclui stdoute, como resultado, você vê o mesmo conteúdo oito vezes.

É uma boa prática chamar fflush()todos os fluxos com saída pendente antes de chamar fork()ou permitir que o filho bifurcado chame explicitamente _exit()que só sai do processo sem liberar os fluxos de stdio.

Observe que a chamada exec()não libera os stdio buffers, portanto, não há problema em se preocupar com os stdio buffers se você (após a chamada fork()) ligar exec()e (se isso falhar) ligar _exit().

BTW: Para entender que o buffer incorreto pode causar, eis um bug anterior no Linux que foi corrigido recentemente:

O padrão requer stderrque não seja stderrarmazenado o buffer por padrão, mas o Linux ignorou isso e tornou a linha armazenada em buffer e (ainda pior) totalmente armazenada em buffer, caso o stderr fosse redirecionado através de um canal. Assim, os programas escritos para UNIX produziram coisas sem nova linha tarde demais no Linux.

Veja o comentário abaixo, parece estar corrigido agora.

Isto é o que eu faço para solucionar esse problema do 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); 

Esse código não faz mal a outras plataformas, já que chamar fflush()um fluxo que acabou de ser liberado é um noop.