On 28Dec2018 20:21, Daniel Ojalvo <d.oja...@f5.com> wrote:
I agree that previous behavior shouldn't be changed, but I would suggest updating the documentation to point it out as a footnote. The current behavior is correct just unclear. Most people just learning about the open command wouldn't have this expectation.
Maybe, maybe not. "Most" is a conjecture. IMO people will only find it surprising if they think any filesystem object can be instantly opened. However that is a misapprehension on their part.
My personal expectation is that open() will come back when the object is open. I don't have a timeframe in mind unless I have a strong expectation about _what_ I'm opening.
I came across the issue when I had a program that would open up all the files in a directory to read a few bytes from the beginning. My concern would be someone just making a named pipe over a file that a program would open.
What about a symlink to a magic /dev/tcp/host:port device, initiating a TCP connection? Particularly if "host" is down or inaccessible? Etc.
Arguably, anyone affected by that would be shooting themselves in the foot to begin with, but I think there are "security" concerns because someone could cause a bit of mischief that would be difficult to diagnose.
It isn't hard to diagnose at all. Point strace at the hung pogram, see it is opening some path, "ls -ld the-path", oooh, it isn't a regular file.
The point here is that if a programme opens every file in a directory, maybe it should constrain itself to regular files. Opening anything else may not just hang, it can have real world side effects. (Usually such effect happen at some point after open, for example opening a rewind take device will physicially rewind the tape on close, but you've committed to that happening by opening it in the first place.)
I think Chris offered the example of a subdirectory to suggest that such a programme already has an opnion about what to open and what to leave alone (unless is _does_ open() subdirectories, which might be useful but is usually misleading and on some OSes unsupported). So the programme should be pickier anyway.
That all being said, I think I would like to put in a feature request for a non-blocking option. How should I go about doing so?
I agree with the suggestion already made: devise a well thought out proposal which fits nicely with the existing open() call (eg an addition to the mode argument or something), and describe it clearly in python-ideas.
Certainly a number of things can be opened in a "nonblocking" mode, which means that reads return instantly if there's no available data, so having an open not block isn't unreasonable to want. But it may be unreasonable to implement in general: OSes may not support it directly.
Cheers, Cameron Simpson <c...@cskk.id.au> -- https://mail.python.org/mailman/listinfo/python-list
