Rilascio di risorse C++ e fork-exec?

Question

Sto provando a generare un nuovo processo dal mio progetto C++ usando fork-exec. Sto usando fork-exec per creare un pipe bidirezionale per il processo figlio. Ma temo che le mie risorse nel processo forked non vengano liberate correttamente, dal momento che la chiamata exec prenderà completamente il mio processo e non chiamerà alcun distruttore.

Ho tentato di aggirare questo problema lanciando un'eccezione e chiamando execl da un blocco catch alla fine del main, ma questa soluzione non distrugge alcun singletons.

Esiste un modo ragionevole per raggiungere questo obiettivo in sicurezza? (Si spera evitando qualsiasi hack AtExit)

Es: le seguenti uscite codice:

We are the child, gogo! 
Parent proc, do nothing 
Destroying object 

Anche se il processo biforcuta ha anche una copia del singleton che deve essere distrutti prima che chiami execl.

#include <iostream> 
#include <unistd.h> 

using namespace std; 

class Resources 
{ 
public: 
    ~Resources() { cout<<"Destroying object\n"; } 
}; 

Resources& getRes() 
{ 
    static Resources r1; 
    return r1; 
} 

void makeChild(const string &command) 
{ 
    int pid = fork(); 
    switch(pid) 
    { 
    case -1: 
     cout<<"Big error! Wtf!\n"; 
     return; 
    case 0: 
     cout<<"Parent proc, do nothing\n"; 
     return; 
    } 
    cout<<"We are the child, gogo!\n"; 
    throw command; 
} 

int main(int argc, char* argv[]) 
{ 
    try 
    { 
     Resources& ref = getRes(); 
     makeChild("child"); 
    } 
    catch(const string &command) 
    { 
     execl(command.c_str(), ""); 
    } 
    return 0; 
} 

Answer 1

ci sono ottime probabilità che non si necessità per chiamare qualsiasi distruttori tra fork e exec. Sì, fork crea una copia dell'intero stato del processo, inclusi gli oggetti che hanno distruttori, e exec cancella tutto quello stato. Ma importa davvero? Può un osservatore esterno al tuo programma - un altro processo non correlato in esecuzione sullo stesso computer - dire che i distruttori non sono stati eseguiti nel bambino? Se non c'è modo di dirlo, non è necessario eseguirli.

Anche se un osservatore esterno può dire, è possibile che attivi in ​​modo errato per eseguire i distruttori nel figlio. Il solito esempio è: immagina di aver scritto qualcosa a stdout prima di chiamare fork, ma è stato memorizzato nella libreria e quindi non è stato ancora consegnato al sistema operativo. In tal caso, l'utente non deve chiamarefclose o fflush su su stdout nel figlio o l'output si verificherà due volte! (Questo è anche il motivo per cui quasi certamente dovrebbe chiamare _exit invece di exit se il exec fallisce.)

Detto questo, ci sono due casi comuni in cui potrebbe essere necessario fare un certo lavoro di pulizia nel bambino. Uno è descrittori di file (non confondere questi con FILE stdio o oggetti iostream) che non dovrebbero essere aperti dopo il exec. Il modo corretto per gestirli è impostare il flag FD_CLOEXEC al più presto dopo che sono aperto (alcuni SO ti permettono di farlo in open stesso, ma non è universale) e/o di passare da 3 a un numero elevato che chiama close (nonfclose) nel bambino. (FreeBSD ha closefrom, ma per quanto ne so, nessun altro lo fa, il che è un peccato perché è davvero abbastanza comodo.)

L'altro caso è un blocco di thread di sistema globale, che - questo è un spinoso e scarsamente standardizzato area - può trattenuto dal padre e dal figlio e quindi ereditato attraverso exec in un processo che non ha idea di contenere un blocco. Questo è ciò che dovrebbe essere pthread_atfork, ma ho letto che in pratica non funziona in modo affidabile. L'unico consiglio che posso offrire è "non tenere serrature quando chiami fork", chiedi scusa.