alister <alister.nospam.w...@ntlworld.com>: > I meant the program that is supplying your app with file handles > willy- nilly without caring what happens to them
You seem to be advocating a strategy whereby the application keeps close track of all file descriptors and closes them individually as needed. Thing is, processes can be forked by library calls. For example, you might have developed a class that converts a synchronous database API into an asynchronous one. You'll have your object fork a helper process that makes blocking calls while the object methods make sure never to block the caller. The application doesn't know the library would be starting a child process. On the other hand, the library has no idea on what files the application might have open. That's why the library traverses all file descriptors and closes them categorically after forking. Marko -- https://mail.python.org/mailman/listinfo/python-list
