RetroSearch Browse

Sat Jul 6 11:23:26 CEST 2013 · https://mail.python.org/pipermail/python-dev/2013-July/127211.html

> 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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2013-July/127211.html below:

[Python-Dev] PEP 446: Add new parameters to configure the inherance of files and for non-blocking sockets