which exception do you get when you os.write() to a pipe that has nothing reading it?

[Skaperen]

which exception do you get when you os.write() to a pipe that has nothing reading it?

---

i thought it would be BrokenPipeError so i tried some tests but i'm not getting anything.

[Gribouillis]

i thought it would be BrokenPipeError so i tried some tests but i'm not getting anything.

Don't you get ANY error message? What does the program do? Does it hang while trying to write into the pipe? Please post the complete code so that we can try it.

If you manage to get a C level error code, you could perhaps build your custom exception by using the errno module and os.strerror().

[Skaperen]

i tried a bunch of things in interactive Python and got a variety of responses but none of them gave an exception. some would hang, with one even blocking Ctrl-C (e.g. ^C would have no effect). when i could check it, the return value was inconsistent. what search string should find this?

[Gribouillis]

Without code, it is very difficult to answer. You could perhaps use poll() or select() with a timeout to detect that the pipe is not ready for writing.

[Skaperen]

it is OK to write into the write end of a pipe even when nothing is reading the other end. this is an essential behavior because after a read completes, there is a period of time until the next read operation is performed. you wouldn't want to have writes just periodically fail because it just happened at the wrong time. to do that, pipes would need to do event synchronization and that's just not done, especially when the writer and reader are ordinary programs that get piped together on a POSIX shell pipeline (these processes are not doing things like select() or poll(). with this i need to go back and re-think what i was trying to do and why.

i'm thinking i need to go back and do some stuff in C, again, just to get my brain thinking about the system.

[Gribouillis]

i'm thinking i need to go back and do some stuff in C, again, just to get my brain thinking about the system.

I wonder if the problem is not related to PEP 475, the fact that a system call which fails with EINTR is automatically retried by the standard library wrappers such as os.write() without raising an exception.

If this is the problem, you could perhaps give your program a chance to handle it by setting a signal handler, perhaps to catch signal.SIGPIPE.

signal.SIGPIPE
Broken pipe: write to pipe with no readers.

Default action is to ignore the signal.

Availability: Unix.

[Skaperen]

SIGPIPE happens when the read end is closed, not when there is just no read() call that is active (the file descriptor, when closed, is no longer there). i was originally confusing this distinction when i was doing the initial logic design of my current project being done in Python. this revealed to me that my memory about the system semantics was fuzzy, hence the idea to do some things in C, again, particularly, using Python to prototype some of those designs.

[Gribouillis]

using Python to prototype some of those designs.

As PEP 475 only applies starting from Python 3.5, you could perhaps try to run your code with Python 3.4. If it raises InterruptedError instead of behaving as it does now, this would clearly indicate PEP 475 as the culprit of your issue.

With a virtual environment, you can easily run your code against Python 3.4.