conf, repair, tap: Document reasons for blocking Unix socketsHEADmaster

Most of our operation is asynchronous, based on non-blocking fds handled
in our epoll loop.  However, our several Unix sockets (tap client, repair
helper, control client) are all blocking fds after accept().

That is in fact correct, but for not especially obvious reasons that are
slightly different in each case.  Add explanatory comments to each of them.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
[sbrivio: Fixed minor coding style detail in comment in conf_accept()]
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>

3 files changed, 16 insertions, 0 deletions

diff --git a/conf.c b/conf.c
index 029b9c7..6f86940 100644
--- a/conf.c
+++ b/conf.c
@@ -2084,6 +2084,13 @@ static void conf_accept(struct ctx *c)
 	int fd, rc;
 
 retry:
+	/* Currently we perform the configuration transaction more-or-less
+	 * synchronously, so we want the accepted socket to be blocking.
+	 *
+	 * FIXME: We should make the configuration update asynchronous, like
+	 * most of our operation, so a misbehaving configuration client can't
+	 * block the main forwarding loop.
+	 */
 	fd = accept4(c->fd_control_listen, NULL, NULL, SOCK_CLOEXEC);
 	if (fd < 0) {
 		if (errno != EAGAIN)
diff --git a/repair.c b/repair.c
index 3e0e3e0..f31ccce 100644
--- a/repair.c
+++ b/repair.c
@@ -99,6 +99,10 @@ int repair_listen_handler(struct ctx *c, uint32_t events)
 		return EEXIST;
 	}
 
+	/* We want the accepted socket to be blocking; we use it during
+	 * migration which is a synchronous interruption to our normal
+	 * non-blocking behaviour.
+	 */
 	if ((c->fd_repair = accept4(c->fd_repair_listen, NULL, NULL,
 				    SOCK_CLOEXEC)) < 0) {
 		rc = errno;
diff --git a/tap.c b/tap.c
index b318327..4cba4c7 100644
--- a/tap.c
+++ b/tap.c
@@ -1492,6 +1492,11 @@ void tap_listen_handler(struct ctx *c, uint32_t events)
 		return;
 	}
 
+	/* Because we generally only access the accepted socket from epoll
+	 * events, it usually doesn't matter if it's blocking or non-blocking.
+	 * However, in rare cases when the socket buffer fills we need (briefly,
+	 * we hope) blocking writes (write_remainder() in send_frames_passt()).
+	 */
 	c->fd_tap = accept4(c->fd_tap_listen, NULL, NULL, SOCK_CLOEXEC);
 	if (c->fd_tap < 0) {
 		warn_perror("Error accepting tap client");