Perché fork () dovrebbe essere stato progettato per restituire un descrittore di file?

Nella sua pagina web sull'inganno del self-pipe , Dan Bernstein spiega una condizione di gara select()e segnala, offre una soluzione alternativa e conclude che

Naturalmente, la cosa giusta sarebbe quella di fork()restituire un descrittore di file, non un ID processo.

Che cosa intende con questo: è qualcosa che riguarda la capacità select()dei processi figlio di gestire i loro cambiamenti di stato invece di dover usare un gestore di segnale per essere avvisati di quei cambiamenti di stato?

Il problema è descritto lì nella tua fonte, select()dovrebbe essere interrotto da segnali simili SIGCHLD, ma in alcuni casi non funziona così bene. Quindi la soluzione alternativa è quella di fare scrivere il segnale su una pipe, che viene quindi guardato da select(). Guardare i descrittori di file è ciò che select()serve, in modo che aggiri il problema.

La soluzione alternativa essenzialmente trasforma l'evento signal in un evento descrittore di file. Se fork()in primo luogo fosse appena restituito un fd, la soluzione alternativa non sarebbe richiesta, poiché tale fd potrebbe quindi essere presumibilmente utilizzato direttamente con select().

Quindi sì, la tua descrizione nell'ultimo paragrafo mi sembra giusta.

Un altro motivo per cui un fd (o qualche altro tipo di handle del kernel) sarebbe migliore di un semplice numero ID di processo, è che i PID possono essere riutilizzati dopo la fine del processo. Questo può essere un problema in alcuni casi quando si inviano segnali ai processi, potrebbe non essere possibile sapere con certezza che il processo è quello che pensi sia, e non un altro che riutilizza lo stesso PID. (Anche se penso che questo non dovrebbe essere un problema quando si inviano segnali a un processo figlio, dal momento che il genitore deve correre wait()sul figlio perché il suo PID venga rilasciato.)

È solo una riflessione sulle linee di "sarebbe bello se Unix fosse progettato diversamente da come è".

Il problema con i PID è che vivono in uno spazio dei nomi globale in cui potrebbero essere riutilizzati per un altro processo, e sarebbe bello se fork()restituito nel genitore un tipo di handle che sarebbe garantito per fare sempre riferimento al processo figlio e che potrebbe passare ad altri processi tramite ereditarietà o unix socket / SCM_RIGHTS[1].

Vedi anche la discussione qui per un recente sforzo per "aggiustare" quello in Linux, inclusa l'aggiunta di un flag a clone()cui lo farà restituire un pid-fd invece di un PID.

Ma anche allora, ciò non eliminerebbe la necessità di quell'hacking self-pipe [2] o di interfacce migliori, poiché i segnali che informano un processo genitore sullo stato di un bambino non sono i soli che vorresti gestire nel ciclo principale del programma. Sfortunatamente, cose come epoll(7) + signalfd(2)su Linux o kqueue(2)su BSD non sono standard: l'unica interfaccia standard (ma non supportata su sistemi più vecchi) è molto inferiore pselect(2).

[1] Prevenire il riciclo del PID entro il tempo in cui la waitpid()syscall era tornata e il suo valore di ritorno usato poteva essere probabilmente ottenuto su sistemi più recenti usando waitid(.., WNOWAIT)invece.

[2] Non vorrei commentare l'affermazione di DJ Bernstein di averlo inventato (scusate l'apofasi ;-)).

Bernstein non dà molto contesto per questa osservazione "Right Thing", ma rischierò un'ipotesi: avere fork (2) restituire un PID non è coerente con open (2), creat (2) ecc. Che restituiscono i descrittori di file. Il resto del sistema Unix avrebbe potuto eseguire la manipolazione del processo con un descrittore di file che rappresenta un processo, anziché un PID. Esiste una chiamata di sistema signalfd (2) , che consente un'interazione leggermente migliore tra segnali e descrittori di file e mostra che un descrittore di file che rappresenta un processo potrebbe funzionare.