However, because of what you have observed I wrote up a quick test, which confirms to my satisfaction that epoll_wait() respects SO_RCVLOWAT on TCP sockets: https://gist.github.com/keaston/d2473b8b996a34a5860b0744684f...
It seems likely that you must have been dealing with an old "enterprise" kernel in 2015 that hadn't had this fix backported to it?
My only guess is that I was botching something else when I was digging into this a few years ago.
I can't tell you how much I appreciate you putting that together. This seriously changes a lot of what I work on. Thank you.
The client code I wrote: https://gist.github.com/benwills/95ee844853d3b18588fb3df7d56...
The errors are just because you need to check for EAGAIN or EWOULDBLOCK when read() returns -1, and not bail out when that happens.
However, because of what you have observed I wrote up a quick test, which confirms to my satisfaction that epoll_wait() respects SO_RCVLOWAT on TCP sockets: https://gist.github.com/keaston/d2473b8b996a34a5860b0744684f...
It seems likely that you must have been dealing with an old "enterprise" kernel in 2015 that hadn't had this fix backported to it?