Esta é uma questão puramente acadêmica, porque isso nunca acontecerá.
Se um PID é armazenado como tipo pid_t, e não algum tipo de precisão arbitrária, então há um limite para o número de PIDs que podem existir ao mesmo tempo. Existe um comportamento definido para quando os PIDs estouram?
O processo 65536ª matará / sbin / init e criará um pânico no kernel? Ou existe alguma medida de segurança?
O fork syscall deve retornar -1 e definir errno para EAGAIN . O que acontece depois disso dependerá do processo que chamou fork .
De garfo :
The fork() function shall fail if:
[EAGAIN]
The system lacked the necessary resources to create another process, or the system-imposed limit on the total number of processes under execution system-wide or by a single user {CHILD_MAX} would be exceeded.
POSIX não especifica que o PID de cada novo processo é obtido incrementando o PID anterior. Apenas requer que seja único.
Em um sistema onde os PIDs são incrementados em cada fork() , observei que os valores se ajustam depois de atingir algum limite superior (que, na minha experiência, é de cerca de 2 15 ). Após o contorno, os novos PIDs não são estritamente incrementados, uma vez que alguns valores de PID ainda estarão em uso nos ciclos anteriores.
Não deve haver um problema até que você tenha 2 N executando simultaneamente processos. Eu suspeito que o sistema teria algum limite de capacidade muito antes disso acontecer. Nesse caso, a chamada do sistema fork() falharia e provavelmente configuraria errno para EAGAIN ou ENOMEM ( man fork para detalhes).
O limite máximo de PID é muito menor que 2^((sizeof(int)*CHAR_BIT) . Consulte Qual é o valor máximo do ID do processo? . Em outras palavras, seus PIDs nunca chegarão a 4 bilhões.
Quando todos os slots pid forem preenchidos, fork chamadas começarão a falhar com errno==EAGAIN (consulte fork (2) ). Se você simplesmente atingiu o topo sem preencher todos os slots, o próximo PID será o próximo slot livre após 1 (1 é o init)