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 <[email protected]> --- 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 _______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
