Procesele cu mai multe fire de execuție și close()¶

Probabil că nu este înțelept să închideți descriptorii de fișier în timp ce aceștia pot fi utilizați de apeluri de sistem în alte fire de execuție din același proces. Deoarece un descriptor de fișier poate fi reutilizat, există unele condiții de concurență ascunse care pot provoca efecte secundare neintenționate.

În plus, luați în considerare următorul scenariu în care două fire efectuează operații pe același descriptor de fișier:

(1)

Un fir este blocat într-un apel de sistem I/O pe descriptorul de fișier. De exemplu, încearcă să efectueze write(2) pe o conductă care este deja plină sau încearcă să efectueze read(2) de la un soclu de flux care nu are în prezent date disponibile.

(2)

Un alt fir închide descriptorul de fișier.

Comportamentul în această situație variază de la un sistem la altul. Pe unele sisteme, atunci când descriptorul de fișier este închis, apelul de sistem blocant returnează imediat cu o eroare.

Pe Linux (și posibil pe alte sisteme), comportamentul este diferit: apelul de sistem I/O blocant deține o referință la descrierea fișierului deschis, iar această referință menține descrierea deschisă până la finalizarea apelului de sistem I/O. (Consultați open(2) pentru o discuție despre descrierile de fișiere deschise). Astfel, apelul de sistem blocant din primul fir poate fi finalizat cu succes după efectuarea close() din al doilea fir.

Gestionarea răspunsurilor eronate de la close()¶

Un programator atent va verifica valoarea de returnare a close(), deoarece este foarte posibil ca erorile de la o operație anterioară write(2) să fie raportate numai la close() final care eliberează descrierea fișierului deschis. Ne verificarea valorii de returnare la închiderea unui fișier poate duce la pierderea silențioasă de date. Acest lucru poate fi observat în special cu NFS și cu cota de disc.

Rețineți, totuși, că o returnare în caz de eșec ar trebui utilizată numai în scopuri de diagnosticare (de exemplu, un avertisment adresat aplicației că este posibil să mai existe operații I/O în așteptare sau că este posibil să fi existat operații I/O eșuate) sau în scopuri de remediere (de exemplu, scrierea fișierului încă o dată sau crearea unei copii de rezervă).

Reîncercarea operației close() după un eșec este un lucru greșit de făcut, deoarece acest lucru poate cauza închiderea unui descriptor de fișier reutilizat de la un alt fir de execuție. Acest lucru se poate întâmpla deoarece nucleul Linux eliberează întotdeauna descriptorul de fișier la începutul operației de închidere, eliberându-l pentru reutilizare; pașii care pot returna o eroare, cum ar fi trimiterea datelor către sistemul de fișiere sau dispozitiv, au loc doar mai târziu în operația de închidere.

În mod similar, multe alte implementări închid întotdeauna descriptorul de fișier (cu excepția cazului EBADF, ceea ce înseamnă că descriptorul de fișier a fost nevalid) chiar dacă ulterior raportează o eroare la returnarea de la operația close(). În prezent, POSIX.1 nu se referă la acest aspect, dar există planuri de a impune acest comportament în următoarea versiune majoră a standardului.

Un programator atent care dorește să știe despre erorile I/O poate precede close() cu un apel la fsync(2).

Eroarea EINTR este un caz oarecum special. În ceea ce privește eroarea EINTR, POSIX.1-2008 spune:

Acest lucru permite comportamentul care apare pe Linux și în multe alte implementări, unde, ca și în cazul altor erori care pot fi raportate de close(), descriptorul de fișier este garantat a fi închis. Cu toate acestea, aceasta permite și o altă posibilitate: ca implementarea să returneze o eroare EINTR și să mențină descriptorul de fișier deschis. Conform documentației sale, close() de la HP-UX face acest lucru. Apelantul trebuie apoi să utilizeze încă o dată close() pentru a închide descriptorul de fișier, pentru a evita scurgerile de informații din descriptorul de fișier. Această divergență în comportamentele de implementare reprezintă un obstacol dificil pentru aplicațiile portabile, deoarece în multe implementări, close() nu trebuie să fie apelat din nou după o eroare EINTR, iar în cel puțin una, close() trebuie să fie apelat din nou. Există planuri de rezolvare a acestei enigme pentru următoarea versiune majoră a standardului POSIX.1.