Multithreaded processen en close()

Het is hoogstwaarschijnlijk niet slim om bestandsindicatoren te sluiten terwijl ze in gebruik kunnen zijn door systeem aanroepen in andere threads in hetzelfde proces. Omdat een bestandsindicator kan worden hergebruikt, zijn er obscure looptijd condities die tot onbedoelde neven effecten kunnen leiden.

Bovendien, overweeg het volgende scenario waar twee threads dezelfde operaties op dezelfde bestandsindicator uitvoeren:

(1)

Een thread wordt geblokkeerd door een Invoer/Uitvoer systeem aanroep op de bestandsindicator. Bijvoorbeeld, hij probeert te write(2) naar een pijp die al vol is, of probeert te read(2) van een stream socket die op dit moment geen gegevens beschikbaar heeft.

(2)

Een andere thread sluit de bestandsindicator.

Het gedrag in deze situatie varieert over systemen. Op sommige systemen, zal de blokkerende systeem aanroep onmiddellijk met een fout beëindigen zodra de bestandsindicator is gesloten

Op Linux (en mogelijk enkele andere systemen), is het gedrag anders: de blokkerende Invoer/Uitvoer systeem aanroep houdt een referentie naar de onderliggende bestandsindicator open, en deze referentie houdt de indicator open totdat de Invoer/Uitvoer systeem aanroep eindigt. (Zie open(2) voor een discussie over open bestandsindicatoren.) Dus kan de blokkerende systeem aanroep in de eerste thread succesvol eindigen na de close() in de tweede thread.

Omgaan met fout meldingen van close()

Een zorgvuldige programmeur controleert de uitvoer waarde van close(), omdat het mogelijk is dat fouten van een vorige write(2) operatie alleen worden gerapporteerd bij de finale close() die de open bestandsindicator vrij geeft. Het niet controleren van de uitvoer waarde bij het sluiten van een bestand kan leiden tot zwijgend verlies van gegevens. Dit kan speciaal optreden met NFS en met schijf quota.

Merk op, dat een fout uitvoer alleen gebruikt mag worden voor diagnose (m.a.w. een waarschuwing aan de applicatie dat er nog een Invoer/Uitvoer bezig kan zijn of dat er gefaalde Invoer/Uitvoer kan zijn) of gebruikt voor reparaties (b.v. het opnieuw schrijven van een bestand of het maken van een backup).

Opnieuw close() proberen na terug melding van een fout is verkeerd om te doen, omdat dat er voor kan zorgen dat een hergebruikte bestandsindicator van een andere thread kan worden gesloten. Dit kan optreden doordat de Linux kernel de bestandsindicator altijd vroeg tijdens de close operatie los laat, daarbij hem voor hergebruik beschikbaar maakt; de stappen die een fout kunnen geven, zoals doorspoelen van data naar het bestandssysteem of apparaat, treden alleen later tijdens de close operatie op.

Veel andere implementatie sluiten de bestandsindicator ook op deze manier (behalve in het geval van EBADF, aangezien dit betekent dat de bestandsindicator ongeldig was) zelfs als deze een vervolgens een fout rapporteren bij terugkeer van close(). POSIX.1 is momenteel stil op dit punt, maar er bestaan plannen om dit gedrag te eisen in een volgende belangrijke uitgave van de standaard.

Een zorgvuldige programmeur die Invoer/Uitvoer fouten wil weten mag de aanroep van close() vooraf laten gaan met een aanroep van fsync(2).

De EINTR fout is een speciaal geval. Betreffende de EINTR fout, zegt POSIX.1-2008:

Dit staat het gedrag toe dat optreedt in Linux en veel andere implementaties waar, zoals bij andere fouten die kunnen worden gerapporteerd door close(), de bestandsindicator gegarandeerd wordt gesloten. Hoewel het ook een andere mogelijkheid opent: dat de implementatie een EINTR fout terug geeft en de bestandsindicator open houdt. (Volgens de documentatie doet de HP-UX close() implementatie dit.) De aanroeper dient nog een keer close() gebruiken om de bestandsindicator te sluiten, om lekken van bestandsindicatoren te voorkomen. Deze verschillen in implementatie gedrag betekenen een moeilijkheid voor overdraagbare applicaties, omdat in veel implementaties close() niet nogmaals hoeft te worden aangeroepen na een EINTR fout, en op zijn minst op een moet close() nog een keer aangeroepen worden. Er bestaan plannen om dit raadsel aan te pakken in een volgende belangrijke uitgave van de POSIX.1 standaard.