come gestire il codice che non viene mai eseguito

Question

Ho un codice simile a questo e non so come gestire la parte che non verrà mai eseguita poiché una parte di questo codice viene eseguita in loop infinito durante l'attesa delle connessioni e quando terminare il programma, esce solo da lì.

main(){ 

// do some stuff.... 

    while(1) { 
     int newFD = 
      accept(sockFD, (struct sockaddr *)&client_addr, &client_addr_size); 
     if(newFD == -1) { 
      std::cerr << "Error while Accepting on socket" << std::endl; 
      continue; 
     } 

     if(!fork()) { 

      close(sockFD); // close child's sockfd - not needed here 

      // lalala do stuff send message here     

      close(newFD); // finally close its newFD - message sent, no use 
      return 0; 
     } 
     close(newFD); // close parent's newFD - no use here 
    } 

    // now execution never reaches here 
    close(sockFD);  // so how to handle this? 
    freeaddrinfo(res); // and this? 

    return 0; 
} 

Answer 1

È possibile, e probabilmente dovrebbe aggiungere un gestore di uscita se il codice deve essere utilizzato da altre persone o ti vogliono solo più pulito. Nel tuo gestore di uscita puoi attivare un flag che interrompe il ciclo while(). Il seguente codice funzionerà al 100% per questo caso d'uso ed è affidabile e multipiattaforma, ma se vuoi fare cose più complicate dovresti usare le funzioni specifiche di thread safe specifiche o qualcosa come Boost o C++ 11

Prima dichiarare due variabili globali, renderle volatili in modo che il compilatore ci costringerà sempre a leggere o scrivere il suo reale valore di memoria. Se non lo dichiariamo volatile, allora è possibile che il compilatore possa mettere il suo valore in un registro che lo renderà non funzionante. Con set volatile legge la posizione di memoria su ogni loop e funziona correttamente, anche con più thread.

volatile bool bRunning=true; 
volatile bool bFinished=false; 

e al posto del tuo while(1) {} ciclo, modificarlo a questo

while(bRunning) 
{ 
    dostuff 
} 
bFinished=true; 

Nel vostro gestore di uscita semplicemente impostare bRunning=false;

void ExitHandler() 
{ 
    bRunning=false; 
    while(bFinished==false) { Sleep(1); } 
} 

Lei non ha specificato un sistema operativo ma sembra come se fossi basato su Linux, per impostare un gestore su Linux hai bisogno di questo.

E su Windows quando si è un'app per console è la seguente.

BOOL WINAPI ConsoleHandler(DWORD CEvent) 
{ 
    switch (CEvent) 
    { 
     case CTRL_C_EVENT: 
     case CTRL_BREAK_EVENT: 
     case CTRL_CLOSE_EVENT: 
     case CTRL_LOGOFF_EVENT: 
     case CTRL_SHUTDOWN_EVENT: 
      bRunning = false; 
      while (bFinished == false) Sleep(1); 
      break; 
    } 
    return TRUE; 
} 

int main() 
{ 
    SetConsoleCtrlHandler(ConsoleHandler, TRUE); 
    while(bRunning() 
    { 
     dostuff 
    } 
    ...error_handling... 
} 

Avviso la necessità di testare e attendere bFinished qui. Se non lo fai su Windows, l'app potrebbe non avere il tempo di spegnersi in quanto il gestore di uscita viene chiamato da un thread specifico del sistema operativo separato. Su Linux questo non è necessario ed è necessario uscire dal gestore per continuare il thread principale.

Un'altra cosa da tenere in considerazione è che, per impostazione predefinita, Windows ti consente di spegnere ~ 5 secondi prima che termini. Ciò è sfortunato in molti casi e, se è necessario più tempo, è necessario modificare le impostazioni del registro (cattiva idea) o implementare un servizio che si adatti meglio a tali cose. Per il tuo caso semplice andrà bene.

Answer 2

Per queste cose, il sistema operativo si occuperà di rilasciare correttamente le risorse all'arresto. Tuttavia, più in generale, è ancora necessario assicurarsi che le risorse allocate non si accumulino durante l'esecuzione del programma, anche se vengono automaticamente recuperate dal sistema operativo, poiché tale perdita di risorse influenzerà ancora il comportamento e le prestazioni del programma.

Ora, per quanto riguarda le risorse disponibili, non c'è motivo di non trattarle come tutte le risorse in C++. La regola accettata è quella di associarli a un oggetto che li rilascerà nel loro distruttore, vedere anche l'idioma RAII. In questo modo, anche se in un secondo momento qualcuno ha aggiunto una dichiarazione break, il codice si comporterebbe comunque correttamente.

BTW: Il problema più serio che vedo qui è la mancanza di una corretta gestione degli errori in generale.