Poniższy Python kod 3 wykazuje pewne dziwne zachowanie (dla mnie przynajmniej), gdy go uruchomić poprzez strace
:Co dzieje się z deskryptorami plików w Pythonie 3, gdy kończy się .close()?
import os
import sys
if len(sys.argv) != 2:
print('Usage: ecpy <filename>')
sys.exit(1)
try:
print('my PID: %d' % os.getpid())
with open(sys.argv[1], 'w') as fp:
try:
fp.write('Hello Stack Overflow!')
except IOError as e:
print('### before close')
print(str(e))
sys.stdout.flush()
except IOError as e:
print('### after close')
print(str(e))
sys.stdout.flush()
print('### after exception block')
sys.stdout.flush()
Od I/O jest buforowane, jeśli uruchomić ten kod z /dev/full
, nie robi” t fail do fp
zamyka się na końcu bloku with
. To nie jest niespodzianka. W Pythonie 2.7.3rc2 (na moim systemie), kod uruchamia obsługi wyjątku po rzeczywiście zamykania deskryptor odpowiadający fp
pliku:
write(3, "Hello Stack Overflow!", 21) = -1 ENOSPC (No space left on device)
close(3) = 0
munmap(0x7f9de3f78000, 4096) = 0
write(1, "### after close\n", 16) = 16
write(1, "[Errno 28] No space left on devi"..., 35) = 35
write(1, "### after exception block\n", 26) = 26
Jednak w Pythonie 3.2.3 (w moim systemie), deskryptor pliku jest nadal otwarty po wykonaniu bloków wyjątków:
write(3, "Hello Stack Overflow!", 21) = -1 ENOSPC (No space left on device)
write(1, "### after close\n", 16) = 16
write(1, "[Errno 28] No space left on devi"..., 35) = 35
write(1, "### after exception block\n", 26) = 26
...
write(3, "Hello Stack Overflow!", 21) = -1 ENOSPC (No space left on device)
write(3, "Hello Stack Overflow!", 21) = -1 ENOSPC (No space left on device)
close(3) = 0
Tłumacz próbuje jeszcze raz napisać do pliku i nie działa w trybie cichym. Kiedy Python rzeczywiście wywołuje close()
? Co to wywołuje? To zachowanie wydaje się przeciekać deskryptor pliku.
Dzięki za złożenie. –