search for: fork_safe

...did not choose to set the new field for many of the various language bindings (it becomes a rather difficult task to prove whether the third-party language binding code is itself using atomic CLOEXEC or fd sanitization). However many of our languages are still stuck as serialized, and the lack of .fork_safe won't impact those thread model anyways. Update the testsuite to skip parallel tests that would otherwise fail when the thread model is crippled. Upcoming patches will then fix the server to audit and fix places where we currently leak fds, and then cripple the thread model only on platforms...

...for many of >> the various language bindings (it becomes a rather difficult task to >> prove whether the third-party language binding code is itself using >> atomic CLOEXEC or fd sanitization). However many of our languages are >> still stuck as serialized, and the lack of .fork_safe won't impact >> those thread model anyways. >> >> Update the testsuite to skip parallel tests that would otherwise fail >> when the thread model is crippled. >> >> Upcoming patches will then fix the server to audit and fix places >> where we currently l...

...t the new field for many of > the various language bindings (it becomes a rather difficult task to > prove whether the third-party language binding code is itself using > atomic CLOEXEC or fd sanitization). However many of our languages are > still stuck as serialized, and the lack of .fork_safe won't impact > those thread model anyways. > > Update the testsuite to skip parallel tests that would otherwise fail > when the thread model is crippled. > > Upcoming patches will then fix the server to audit and fix places > where we currently leak fds, and then cripple...

...and NONBLOCK Revert "RHEL 5: Define O_CLOEXEC and SOCK_CLOEXEC." build: Audit existing use of SOCK_CLOEXEC cow, cache: Better mkostemp fallback build: Audit for use of pipe2 rate: Atomically set CLOEXEC on fds server: Use atomic CLOEXEC for nbdkit_read_password plugins: Add .fork_safe field server: Atomically set CLOEXEC on accept fds filters: Set CLOEXEC on files opened during .config python: Use CLOEXEC on script sh: Use pipe2 with CLOEXEC when possible sh: Enable parallel thread model, when possible sh: Test for fd leaks temp debug docs/nbdkit-plugin.pod...

...; + goto error; + } + if (pipe2 (out_fd, O_CLOEXEC) == -1) { + nbdkit_error ("%s: pipe2: %m", script); + goto error; + } + if (pipe2 (err_fd, O_CLOEXEC) == -1) { + nbdkit_error ("%s: pipe2: %m", script); + goto error; + } +#else + /* Without pipe2, we leave .fork_safe at 0 which forces + * NBDKIT_THREAD_MODEL_SERIALIZE_ALL_REQUESTS, this in turn ensures + * no other thread will be trying to fork, and thus we can skip + * worrying about CLOEXEC races. Adding full parallel support on + * this system would require a loop after fork to close all + * unexp...

...r example, a script can use the success or failure of 'mkdir' on a coordinated filename to learn if it is first past the gate, or set up FIFOs for interprocess communication). Thus, it is time to promote the sh plugin to fully-parallel, when supported by the underlying system. (Thanks to .fork_safe, Haiku remains serialized so as to avoid one thread fork()ing while another may leak an fd). The new test copies heavily from test-parallel-file.sh, and also checks for some of the leaks plugged in recent previous patches. Signed-off-by: Eric Blake <eblake@redhat.com> --- plugins/sh/nbdkit...

...XEC; the next patch will actually put accept4() to use. Maybe this penalization will encourage Haiku to implement atomic CLOEXEC sooner. Accordingly, the testsuite is tweaked to skip tests that require parallel execution. Signed-off-by: Eric Blake <eblake@redhat.com> --- This replaces my .fork_safe patch; I've rebased the rest of the series on top of it, including fixing the sh default to serialize if there is no explicit opt-in to parallel, and pushed. docs/nbdkit-plugin.pod | 19 +++++++++++++++---- configure.ac | 1 + common/utils/utils.c | 6 ++++-- serv...

...se the success or failure of > 'mkdir' on a coordinated filename to learn if it is first past the > gate, or set up FIFOs for interprocess communication). > > Thus, it is time to promote the sh plugin to fully-parallel, when > supported by the underlying system. (Thanks to .fork_safe, Haiku > remains serialized so as to avoid one thread fork()ing while another > may leak an fd). > > The new test copies heavily from test-parallel-file.sh, and also > checks for some of the leaks plugged in recent previous patches. > > Signed-off-by: Eric Blake <eblake@re...