Por que os descritores de arquivos são compartilhados entre processos bifurcados?

Question

Quando nós fork() um processo, o processo filho herda os descritores de arquivo. A questão é, por quê?

Como eu estou vendo, compartilhar o descritor de arquivos é uma dor de cabeça quando todo processo está tentando rastrear onde o ponteiro do r / w está.

Por que essa decisão de design foi tomada?

    

Answer 1

explica o raciocínio assim :

There are two reasons why POSIX programmers call fork(). One reason is to create a new thread of control within the same program (which was originally only possible in POSIX by creating a new process); the other is to create a new process running a different program. In the latter case, the call to fork() is soon followed by a call to one of the exec functions.

Quando fork() é usado como um "encadeamento de pobre", faz sentido copiar os descritores de arquivo. Esse caso de uso deve continuar sendo suportado, então esse recurso permanecerá ...

    

Answer 2

Considere um fragmento de shell

{ somecmd; othercommand *.txt; } > outputfile

O shell abre outputfile uma vez, ao iniciar o redirecionamento, e passa o identificador de arquivo para somecmd e othercmd , processa fork s desativado. Dado o agrupamento, o usuário pode não estar errado em esperar que a saída de ambos os comandos acabe em outputfile , da mesma forma que eles acabariam na tela. (Isso seria o mesmo se o grupo { } fosse um script de shell).

Se a posição do arquivo fosse independente para todos os processos, a saída de othercommand iria prejudicar a saída de somecmd . Se um fork redefinir a posição no identificador de arquivo, o shell não teria como passar othercommand um identificador que apontava para o final de outputfile (como era após somecmd ). Nós teríamos que usar um pipe para coletar a saída de ambos os comandos (eles são independentes da posição de qualquer maneira), e ter outro programa concatenando a saída dos dois:

{ somecmd; othercommand *.txt } | cat > outputfile