Undocumented issue: Open system call blocks on named pipes (and a feature request)

Chris Angelico rosuav at gmail.com
Fri Dec 28 12:40:26 EST 2018

On Sat, Dec 29, 2018 at 4:24 AM Grant Edwards <grant.b.edwards at gmail.com> wrote:
> On 2018-12-27, Daniel Ojalvo via Python-list <python-list at python.org> wrote:
> >>>> open("this_is_a_pipe")
> ><blocks>
> Opening a tty device can also block[1].  However, if somebody is using
> the open() builtin on tty devices that's probably the least of their
> problems.

Depending on what you mean by "block", pretty much anything can. It's
not indefinite, but this is clearly an example of blocking behaviour:

rosuav at sikorsky:~$ mkdir gideon_home
rosuav at sikorsky:~$ sshfs gideon: gideon_home/
rosuav at sikorsky:~$ python3
Python 3.8.0a0 (heads/master:8b9c33ea9c, Nov 20 2018, 02:18:50)
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.time(); open("gideon_home/.bashrc"); time.time()
<_io.TextIOWrapper name='gideon_home/.bashrc' mode='r' encoding='UTF-8'>

Due to the latency introduced by having a completely-out-of-cache
remote access directory, simply opening an ordinary file with an
ordinary path took over half a second. But *this* type of blocking
access is NOT changed by adding os.O_NONBLOCK; it will still take that
half second even if you say "opener=nonblock". OTOH, this form of
blocking is a lot safer - normal file systems [1] might be slow, but
they can't deadlock, whereas a pipe most certainly could.


[1] Of course, you could use fusermount and shenanigans to do
basically anything. But at that point, you're deliberately shooting
yourself in the foot, and all I can advise is "don't do that".

More information about the Python-list mailing list