[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Libguestfs] [nbdkit PATCH 9/8] sh: Document CLOEXEC considerations



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 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]