On 8/1/19 5:06 AM, Eric Blake wrote:
On 8/1/19 4:15 AM, Richard W.M. Jones wrote:
On Thu, Aug 01, 2019 at 10:06:01AM +0100, Richard W.M. Jones wrote:
As far as I can see Haiku (hrev52698) has O_CLOEXEC but NOT SOCK_CLOEXEC. As this version is a little old I'll do an update and see if newer versions support it.
I'm on hrev53313+1 which also doesn't appear to have SOCK_CLOEXEC (nor does it have accept4).
Ouch. Then I'm seriously thinking of a followup patch which either forces SERIALIZE_ALL_REQUESTS on all plugins when SOCK_CLOEXEC is missing, or which adds a bool to the plugin interface that the plugin sets to true if it does not fork (default to false), and where we force SERIALIZE_ALL_REQUESTS plugins which have not set it to true (most of our in-tree plugins can set the bool to true).
In fact, this is probably still worthwhile, but I could possibly go one step further - you can ALSO set the bool that you are fork-safe if, in between fork and exec, you close all fds that happened to be leaked (that benefits from something like BSD's closefrom() for bulk-closing, or from glibc's ability to do opendir("/proc/self/fd") after fork in spite of POSIX stating that because opendir is not required to be async-signal-safe you could deadlock on other platforms). We do NOT want nbdkit to do the close-all-fds dance in general, only on platforms where we don't have atomic CLOEXEC (because nbdkit is the main program, we should have absolute control over all fds created). Note that the stance in libvirt is opposite: because that is a library, and may be linked in with a 3rd-party main executable that did not religiously use atomic CLOEXEC, libvirt has no choice but to do the close-all-fds dance on every fork. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org