As long as we have SERIALIZE_ALL_REQUESTS, we don't have to worry
about one thread processing a fork() while another thread might be
opening an fd. But add comments to the code to remind us to fix
things if we ever decide to add more parallelism.
Signed-off-by: Eric Blake <eblake(a)redhat.com>
---
plugins/sh/call.c | 4 ++++
plugins/sh/sh.c | 3 +++
2 files changed, 7 insertions(+)
diff --git a/plugins/sh/call.c b/plugins/sh/call.c
index 871de5c6..da2651d4 100644
--- a/plugins/sh/call.c
+++ b/plugins/sh/call.c
@@ -94,6 +94,10 @@ call3 (const char *wbuf, size_t wbuflen, /* sent to stdin */
*rbuflen = *ebuflen = 0;
rbufalloc = ebufalloc = 0;
+ /* As long as we use NBDKIT_THREAD_MODEL_SERIALIZE_ALL_REQUESTS, we
+ * don't have to worry about CLOEXEC, because we know no other
+ * thread is competing to fork at the same time as this one.
+ */
if (pipe (in_fd) == -1) {
nbdkit_error ("%s: pipe: %m", script);
goto error;
diff --git a/plugins/sh/sh.c b/plugins/sh/sh.c
index aeb01918..1e000b11 100644
--- a/plugins/sh/sh.c
+++ b/plugins/sh/sh.c
@@ -257,6 +257,9 @@ sh_config_complete (void)
}
}
+/* Do not change this to be more parallel without first fixing
+ * potential CLOEXEC races in call.c.
+ */
#define THREAD_MODEL NBDKIT_THREAD_MODEL_SERIALIZE_ALL_REQUESTS
static int
--
2.20.1