Por que um fork é frequentemente seguido por um exec?

fork()cria um novo processo, que é uma cópia do processo pai. Então, se você fizesse apenas fork(), você teria dois processos idênticos em execução. Portanto, para substituir o processo bifurcado por outro código, você precisa executar exec()o que substitui o processo em execução no momento pelo arquivo executável especificado.

O kernel do Linux é organizado dessa maneira. Você não tem uma única chamada de sistema que cria um novo processo e carrega um novo executável ao mesmo tempo. Você tem que fazer isso em duas etapas - primeiro crie um novo processo e, em seguida, carregue um novo executável nesse novo processo. (Embora você possa ter uma função de biblioteca em sua linguagem de programação que combina esses dois - por exemplo, há spawn()muitas variantes C).

Às vezes exec()não é necessário, se apenas criar outra cópia do processo atual é tudo o que você deseja. Muitos daemons, por exemplo, fazem isso.

Isso se deve a razões históricas: no início dos tempos havia apenas forke exec. Porque era fácil de implementar (de acordo com DMR: apenas 27 linhas de código de montagem PDP-7 para fork! - veja, por exemplo , A fork()in the road (Baumann, Appavoo, Krieger, Roscoe, 2019) - uma fonte secundária, embora faça referência a um primário fonte A Evolução do sistema de compartilhamento de tempo Unix (Ritchie, 1979) De qualquer forma, a verdadeira criação de processos diretos ab initio veio muito, muito, muito, muito mais tarde. (E não está no POSIX, possivelmente?)

O fato de que uma verdadeira API de criação direta de processos veio muito mais tarde afeta a programação Unix até hoje. Porque centenas de livros, manuais, tutoriais, apresentações de slides e cursos foram escritos explicando forke execensinados a estudantes e programadores por décadas como a maneira de fazer criação/controle de processos em Unix e essa extensa herança persiste na forma como o código está escrito até hoje .

Ah, aqui está A Evolução do Sistema Unix de Compartilhamento de Tempo (Ritchie, 1979) . Role para baixo até a página 6 para ver: "O controle de processo em sua forma moderna foi projetado e implementado em alguns dias. ..... Na verdade, a chamada de bifurcação do PDP-7 exigiu precisamente 27 linhas de código de montagem."

Porque um exec não cria um processo, e o linux não tem um único syscall para criar processo e carregar executável porque isso só funciona no caso trivial de criar um processo com novo executável sem recursos preexistentes. Se você quiser fazer algo além do caso trivial, a complexidade aumenta rapidamente e fica mais fácil ter etapas separadas de 'criar processo' e 'iniciar executável' com a capacidade de manipular o processo entre elas. Veja https://lwn.net/Articles/360556/ para uma discussão sobre isso.

O Unix, voltando às versões mais antigas, resolveu isso usando fork para criar uma duplicata do processo pai dedicado à configuração do ambiente, que carrega o novo executável, uma vez concluído. O processo filho existe em um estado temporário de acesso a todos os recursos do processo pai, mas de execução no processo filho. Essa abordagem tem algumas vantagens:

1. Você pode usar as APIs de manipulação em processo existentes para configurar o processo filho. Isso significa que você não precisa de uma família inteira de chamadas de API para manipular o processo filho para configurar recursos.
2. Você pode usar exec por conta própria se o processo pai não precisar mais existir após a criação do novo.
3. Você pode bifurcar sem usar exec se quiser um segundo processo do mesmo executável.

Uma perspectiva ligeiramente diferente da maioria das respostas existentes "fork-shaming" ... ;)

Originalmente era provavelmente, como @davidbak mencionou, tão tentadoramente fácil de fazer dessa maneira. Mas tendo trabalhado muito com fork/ exec(e também muitas vezes apenas com fork, para multiprocessamento), definitivamente existem razões pelas quais essa maneira de trabalhar ainda está viva e chutando, e não delegada ao nevoeiro da história:

• Ainda é extremamente simples do ponto de vista de um programador em literalmente qualquer linguagem de programação. Não importa onde eu esteja codificando - qualquer linguagem pode confiar nas implicações extremamente simples da forksemântica e oferecê-la como parte da linguagem. Portanto, toda linguagem tem um método relativamente trivial (comparado ao multithreading em processo) de oferecer pelo menos multiprocessamento para seus usuários.
• Como usuário (programador), posso escrever meu multiprocessamento em poucas linhas de código, sem me preocupar com mutexes, semáforos, sobrescrevendo ilegalmente o estado de qualquer variável do meu programa e assim por diante. Ao mesmo tempo, a "comunicação inicial" entre o pai filho também é tratada de maneira trivial para mim - o filho tem acesso total a qualquer variável ou RAM que o pai tinha e pode continuar trabalhando com ele. Na prática, isso significa que, se eu, digamos, precisar executar algum processo curto de E/S ou de rede em paralelo ao meu programa principal, posso fazer isso com algumas linhas de código; tudo está em um só lugar, facilmente visível. Posso pegar a criança depois e seguir meu caminho. Não há "threads de trabalho", não preciso me preocupar em usar apenas métodos ou estruturas de dados seguros para threads.
• Novamente, como o conteúdo da memória começa idêntico, mas na verdade é separado, não há risco de sobrescrever qualquer coisa entre os processos pai/filho. Sim, eu tenho que encontrar outras maneiras de IPC entre pai e filho, mas esses métodos também não são tão difíceis ; muitas vezes, as linguagens oferecem uma função padrão como "open3" ou algo parecido que fornece automaticamente identificadores de arquivo baseados em pipe bidirecionais para comunicação para evitar deadlocks e tal.
• Especificamente, ao alternar entre linguagens de programação, uma vez que você tenha entendido a forksemântica, nunca mais precisará aprender mais sobre o novo ambiente - é sempre tão simples quanto em qualquer outra linguagem.
• É bom ter de execqualquer maneira. Ele nos permite substituir a imagem do processo atual (ou seja, o executável que está sendo executado) por algo diferente. Isso torna limpo, digamos, ter algum script ou programa que prepare algum tipo de ambiente e depois execute outra coisa, enquanto desaparece da cena. Não apenas libera recursos (RAM, mas também espaço na tabela de processos e assim por diante), mas deixa muito claro para qualquer pessoa envolvida ou olhando para ele que o antigo pai não desempenhará mais nenhum papel no futuro . Muitas vezes você encontra isso em bashscripts bem escritos, que liberam os recursos do bashintérprete ao iniciar sua "carga útil".

Além disso:

• Ele se encaixa perfeitamente na filosofia Unix de ter muitas ferramentas pequenas que podem interagir umas com as outras, em vez de caixas pretas gordas que são muito limitadas ou precisam de um grande conjunto de parâmetros ou uma API para realmente usar.
• Conforme mostrado acima, ele é poderoso em alguns cenários em que apenas uma única função seria limitante; mas também é fácil ter fork+ execseguindo um ao outro. Não é como se você tivesse que fazer muitas coisas no meio (ou qualquer coisa, na verdade), a menos que você precise.
• De acordo com as páginas man, em alguns Unixes modernos (ou seja, Linux), o próprio fork é apenas um wrapper em torno da chamada clone mais moderna e mais poderosa , que de fato é um pouco como um arquivo fork+exec. Observe que aqui vemos a complexidade já levantando sua cabeça feia; O Linux também tem uma função clone3 que substitui clonee torna a interface um pouco mais fácil ou mais conveniente (usando structsao invés de tantos sinalizadores).

Não, você não pode criar um novo processo no UNIX, você só pode duplicar seu processo atual (usando fork). Se você deseja que o novo processo faça algo diferente do que o processo atual está fazendo, você o substitui (usando exec).

Você não precisa forkantes de ligar exec. Há um uso comum em scripts que iniciam uma sessão de login ( .xinitrce similares) onde você configura variáveis ​​de ambiente e inicia tarefas em segundo plano (como ssh-agent) e, em seguida, executa o gerenciador de sessões. Não há mais nada para o script de inicialização fazer depois de iniciar o gerenciador de sessões, para que você execlibere os recursos atribuídos à execução do script de inicialização. O pai do script de inicialização não tem conhecimento dessa substituição - o PID permanece o mesmo - então eles continuam esperando que esse filho morra antes de executar suas ações de limpeza.