[DragonFlyBSD - Bug #3307] select() not working as expect when a pipe is closed

[bugtracker-admin at leaf.dragonflybsd.org]

Issue #3307 has been updated by dillon.


It will set a HUP condition on the descriptor.  It still has to be flagged writable regardless because most programs detect the closed pipe by trying to write() to it.   For poll*() there is a specific POLL_HUP flag.

For select() its really up in the air.   EOF on read is not considered an error of any sort, and that throws confusion on whether EOF on write should be considered an error or not.  Pipes can be half-closed via shutdown() as well as fully closed, for example, and it is unclear whether the two situations should be handled differently or not.  I don't think we currently set exceptfds bits for the condition, and it is unclear whether we should.  Mostly this comes down to ports compatibility and what linux does.  So if someone wants to test what a closed pipe does to select() on linux, I'm happy to do the same thing on DFly.

-Matt

----------------------------------------
Bug #3307: select() not working as expect when a pipe is closed
http://bugs.dragonflybsd.org/issues/3307#change-14229

* Author: tmunro
* Status: Resolved
* Priority: High
* Target version: 6.0
* Start date: 2021-11-19
----------------------------------------
When a the write end of a pipe is in the writefds set of a call to select(), and the read end is closed, I think select() should report the descriptor as writable (because writing would produce EPIPE or SIGPIPE), but it does not.  We suspect this changed, and we noticed the change in the PostgreSQL build farm after upgrading an ancient Dragonfly build machine to the current release.  In our real usage, this causes Perl IPC::Run in our test harness to hang, but here's a minimal repro in C:

https://www.postgresql.org/message-id/flat/CA%2BhUKG%2BUZi3tp%3De0ffO1R7eZ%3Dx8azSJDNzO0E2zOy9PhuyOpAQ%40mail.gmail.com#f90edeec19759a8b62ce98ea5a11cb6e

(Please disregard the discussion of kqueue problems on ancient macOS, which turned out to be a separate problem, completely unrelated).



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account