[BUG] fix truncated responses with sepoll
Due to the way Linux delivers EPOLLIN and EPOLLHUP, a closed connection
received after some server data sometimes results in truncated responses
if the client disconnects before server starts to respond. The reason
is that the EPOLLHUP flag is processed as an indication of end of
transfer while some data may remain in the system's socket buffers.
This problem could only be triggered with sepoll, although nothing should
prevent it from happening with normal epoll. In fact, the work factoring
performed by sepoll increases the risk that this bug appears.
The fix consists in making FD_POLL_HUP and FD_POLL_ERR sticky and that
they are only checked if FD_POLL_IN is not set, meaning that we have
read all pending data.
That way, the problem is definitely fixed and sepoll still remains about
17% faster than epoll since it can take into account all information
returned by the kernel.
diff --git a/include/types/fd.h b/include/types/fd.h
index 488887a..1f1b3b4 100644
--- a/include/types/fd.h
+++ b/include/types/fd.h
@@ -45,16 +45,19 @@
DIR_SIZE
};
-
+/*
+ * FD_POLL_IN remains set as long as some data is pending for read.
+ * FD_POLL_OUT remains set as long as the fd accepts to write data.
+ * FD_POLL_ERR and FD_POLL_ERR remain set forever (until processed).
+ */
#define FD_POLL_IN 0x01
#define FD_POLL_PRI 0x02
#define FD_POLL_OUT 0x04
#define FD_POLL_ERR 0x08
#define FD_POLL_HUP 0x10
-#define FD_POLL_ANY 0x1F
-#define FD_POLL_RD (FD_POLL_IN | FD_POLL_ERR | FD_POLL_HUP)
-#define FD_POLL_WR (FD_POLL_OUT | FD_POLL_ERR | FD_POLL_HUP)
+#define FD_POLL_DATA (FD_POLL_IN | FD_POLL_OUT)
+#define FD_POLL_STICKY (FD_POLL_ERR | FD_POLL_HUP)
/* info about one given fd */
struct fdtab {