DragonFlyBSD

Just a guess... Shouldn't a descriptor in such state (ie. remote end has closed connection) be reported in exceptfds instead of writefds? I'd expect this to be a more reasonable behaviour, as such descriptor is simply not writable, so reporting it writable is kind-of non-sense.

And, AFAIR, in case the remote closes connection "properly", the descriptor should appear in readfds, and read()ing from it then returns zero. That's "the correct" way to detect connection closed by remote.

Thanks!

Hi again, will the fix be MFC'd to the 6.0 branch? Thanks,

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

It's MFC'ed now.