È normale che il bambino in un fork() chiami exec() o _exit() .
Esistono scenari realistici in cui figlio potrebbe tornare dalla funzione che ha chiamato fork() invece?
void foo() {
pid_t pid = fork();
if(pid == 0) {
...
return; //<-- the child is going to unwind the cloned call stack
}
...
Quindi quali usi legittimi ci sono per un bambino biforcuto che ritorna? Ci sono standard che governano questo?
Un banale esempio di dove la funzione chiamata fork dovrebbe restituire sia in parent e child sia se la funzione che chiama fork è una semplice funzione wrapper, e il chiamante di che la funzione è quella che sceglie cosa fare nel genitore e cosa nel bambino. Una semplice funzione wrapper potrebbe non avere molto senso per C pura, ma i binding POSIX C ++ potrebbero legittimamente voler fornire una funzione posix::fork() che chiama semplicemente la funzione globale fork() , ma può essere dichiarata in un'intestazione che non inquina il globale namespace.
l'uomo delle caverne ha dato un buon esempio meno banale in un commento sulla tua domanda.
Gli standard rilevanti affrontano questo problema non risolvendolo. La descrizione di fork() viene specificata senza alcuna restrizione sul ritorno dalla funzione che la chiama, quindi le implementazioni non possono scegliere di non accettarla.
È come la descrizione di putchar non dice che le implementazioni non possono scegliere di non stampare 'a' , ma se un'implementazione lo ha fatto, sono abbastanza sicuro che saremmo perfettamente d'accordo che quello è non è quello che dicono gli standard, non è quello che intendevano dire gli standard, e interpretarlo in questo modo è semplicemente sciocco.
Un figlio che chiama exec non è terminato, è sostituito da un nuovo programma (eseguito nello stesso processo ).
E il execve (2) syscall potrebbe fallire per diversi motivi (quindi tu sempre dovrebbe gestire un tale fallimento). Quindi l'esecuzione continua dopo exec !
Leggi per es. Advanced Linux Programming per i dettagli. Ha almeno un intero capitolo su questi problemi.