> I've read your "Rejected Alternatives" more closely and Ulrich > Drepper's article, though I think the article also supports adding > a blocking (default True) parameter to open() and os.open(). If you > try to change that default on a platform where it doesn't work, an > exception should be raised.
Contrarily to close-on-exec, non-blocking only applies to a limited type of files (e.g. it doesn't work for regular files, which represent 90% of open() use cases). Also, one of the main reasons for exposing close-on-exec in open()/socket() etc is to make it possible to create file descriptors with the close-on-exec flag atomically, to prevent unwanted FD inheritance especially in multi-threaded code. And that's not necessary for the non-blocking parameter. Those are two reasons why IMO "blocking" doesn't have to receive the same treatment as close-on-exec (there's also the Windows issue but I'm not familiar with it). cf _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
