process: Wake up read and write on EPOLLERR

[kleimkuhler]

Motivation

#2174

On epoll platforms, the read end of a pipe closing is signaled to the write end
through the EPOLLERR event [1]. If readiness is not registered for this
event, it will silently pass through epoll_wait calls.

Additionally, this specific case that EPOLLERR is triggered leaves the write
end of the pipe (parent process) waiting for a wakeup that never occurs.

Solution

Similar to the HUP event on Unix platforms, errors are now always masked
through registrations so that both read and write ends of a connection are made
aware of errors.

In cases where pipes are used and the read end closes, write ends that are
waiting for a wakeup are properly notified and try to write again. This allows
a client to observe BrokenPipe and go through the proper cleanup and/or
restablishment of connection.

Closes #2174

Signed-off-by: Kevin Leimkuhler kevin@kleimkuhler.com

[ipetkov]

Implementation looks good to me! 👍

However, CI seems to be hanging?

[kleimkuhler]

It appears kqueue possibly has different behavior on FreeBSD than MacOS.. unfortunately don't see much online about possible differences. Both MacOS and FreeBSD have the same EVFILT_WRITE documentation about what happens when the reader of a pipe disconnects.

[daniel-emotech]

@kleimkuhler I don't know if this is of any help: https://stackoverflow.com/questions/49481723/difference-in-kqueue-handling-of-fifos-between-mac-os-and-freebsd

Also, I tried to try this out but I'm using a tonic server and when I switch to your pr branch I get thread 'main' panicked at 'there is no reactor running, must be called from the context of Tokio runtime'. No such error when I use the 0.2.11 version on crates.io.

[kleimkuhler]

@daniel-emotech I looked into the SO issue as well as a few others and unfortunately have not found anything helpful. If either of the expected flags were set, there would still be an EVFILT_WRITE filter returned which does not appear to be the case. I don't have a FreeBSD setup to test this on, so I'm just removing the test from that target for now.

If someone comes along with this issue on FreeBSD, then there will at least be the chance to ask them for strace output of what is going on.

[daniel-emotech]

Awesome, do you think this will make it into the next release? Just asking cause I'm currently using a timeout to detect when this occurs and then just never joining threads it happens to which is less than ideal 😬. The only saving grace is it only happens with a certain type of media file no clients have sent to the API just my own internal testing 👀