Alain Ketterlin <al...@universite-de-strasbourg.fr.invalid>: > Marko Rauhamaa <ma...@pacujo.net> writes: >> First, if close() fails, what's a poor program to do? > > Warn the user? Not assume everything went well? It all depends on the > application, and what the file descriptor represents.
The problem here is in the system call contract, which is broken. There's no fix. The man page admonition is just hand-waving without constructive advice. >> Try again? > Could be a good idea on NFS or other kind of mounts. Maybe close() will fail for ever. > I can't imagine why one would like to mass-close an arbitrary set of > file descriptors, That's standard practice before execking a file. Failure to do that can seriously hurt the parent process. For example, the parent (or child) will never read an EOF from file descriptor if its duplicate is open in an unwitting child process. Also, the number of open files in the system may grow over all limits or simply waste kernel resources. Close-on-exec is nice, maybe. However, you don't have control over all file descriptors. Loggers, high-level library calls and others open files without the application programmer knowing or having direct control over. > and I think APIs like os.closerange() are toxic and an appeal to > sloppy programming. And you recommend what instead? Marko -- https://mail.python.org/mailman/listinfo/python-list