Procesy wielowątkowe i close()

Prawdopodobnie nie jest roztropnie zamykać deskryptory pliku w chwili, gdy mogą być one używane przez wywołania systemowe w innych wątkach tego samego procesu. Ponieważ deskryptora pliku można użyć ponownie, istnieją pewne zawiłe sytuacje hazardu, które mogą przynieść pewnie nieprzewidziane skutku uboczne.

Co więcej, proszę rozważyć następujący scenariusz, gdy dwa wątki przeprowadzają operacje na tym samym deskryptorze pliku:

(1)

Jeden wątek jest zablokowany w wywołaniu wejścia/wyjścia na deskryptorze pliku. Może to być na przykład próba write(2) do zapełnionego potoku lub próba read(2) z gniazda strumieniowego, które aktualnie nie dysponuje danymi.

(2)

Inny wątek zamyka deskryptor pliku.

Zachowanie w takiej sytuacji różni się w różnych systemach. W niektórych, po zamknięciu deskryptora pliku, blokujące wywołanie systemowe natychmiast powróci z błędem.

W Linuksie (i prawdopodobnie w niektórych innych systemach) zachowanie jest inne: blokujące wywołanie systemowe wejścia/wyjścia utrzymuje referencję do podległego opisu otwartego pliku (OFD) i to odniesienie utrzymuje opis otwarty do momentu zakończenia wywołania systemowego wejścia/wyjścia (zob. open(2) aby dowiedzieć się więcej o opisach otwartego pliku). Z tego względu, blokujące wywołanie systemowe w pierwszym wątku może się pomyślnie zakończyć po close() w drugim wątku.

Zajmowanie się błędami zwróconymi przez close()

Ostrożny programista sprawdzi wartość zwracaną przez close(), ponieważ może się zdarzyć, że błędy wcześniejszej operacji write(2) zostaną zgłoszone jedynie przy kończącym close(), zwalniającym opis otwartego pliku (OFD). Niesprawdzenie zwróconej podczas zamykania pliku wartości może doprowadzić do niesygnalizowanej utraty danych. Jest to obserwowane zwłaszcza w przypadku NFS i przy używaniu przydziałów dyskowych.

Proszę jednak zauważyć, że zwrócenie błędu powinno być używane jedynie do celów diagnostycznych (tj. jako ostrzeżenie dla aplikacji, że wciąż może istnieć oczekujące wejście/wyjście lub wejście/wyjście mogło się nie powieść) lub do celów zaradczych (np. ponowny zapis pliku lub utworzenie kopii).

Ponowna próba wykonania close() po zwróceniu błędu nie jest właściwym zachowaniem, ponieważ może to spowodować zamknięcie użytego ponownie deskryptora pliku z innego wątku. Może się tak zdarzyć, ponieważ jądro Linux zawsze uwalnia deskryptor plików wcześnie przy operacji zamykania, zwalniając go do ponownego użytku; kroki mogące zwrócić błąd, takie jak opróżnianie danych do systemu plików lub urządzenia, mogą wystąpić przy operacji zamykania jedynie później.

Większość innych implementacji zachowuje się podobnie zamykając deskryptor plików zawsze (z wyjątkiem EBADF oznaczającego, że deskryptor pliku był nieprawidłowy) nawet, gdy następnie zwrócą błąd przy powrocie z close(). POSIX.1 nie wypowiada się obecnie na ten temat, ale istnieją plany nakazania tego zachowania w następnym głównym wydaniu standardu

Ostrożny programista, chcący posiąść informacje o błędach wejścia/wyjścia, może poprzedzić close() wywołaniem do fsync(2).

Błąd EINTR jest poniekąd szczególnym przypadkiem. Odnośnie błędu EINTR norma POSIX.1-2008 wspomina:

Zezwala to na zachowanie występujące w Linuksie i wielu innych implementacjach, gdzie, jak w przypadku innych błędów, jakie może zwrócić close(), deskryptor pliku zostanie na pewno zamknięty. Istnieje jednak również inna możliwość: że implementacja zwróci błąd EINTR i utrzyma otwarty deskryptor pliku (zgodnie z dokumentacją HP-UX, jego close() tak czyni). Wywołujący musi wówczas użyć close() ponownie, aby zamknąć deskryptor pliku i aby uniknąć wycieku deskryptora pliku. Ta rozbieżność w implementacji czyni trudności przenośnym aplikacjom, ponieważ w wielu implementacjach close() nie musi być ponownie wywoływane po błędzie EINTR, a w przynajmniej jednej, close() musi być ponownie wywołane. Istnieją plany rozwiązania tej zagwozdki w następnym głównym wydaniu standardu POSIX.1.