On 09/07/2018 05:06 PM, Bruno Haible wrote:
Eric Blake wrote:
Although it gets prohibitively expensive in a multi-threaded process to
ensure proper locking between all threads that might want to use
posix_spawn
Why locking? posix_spawn uses fork() - the vfork() optimization is not
possible in the case when there are file actions -, which creates a
child process with a single thread. So, in the child, there are no
other threads until the exec() call, and the condition variables,
mutexes, etc. are just inactive memory regions.
Calling:
chdir("temp")
posix_spawn()
chdir("restore")
is what requires locking, because POSIX does not (yet) have a way to
guarantee a chdir in the child.
Adding posix_spawn_file_actions_addchdir() is what avoids the need to
lock in the parent, because now you do:
posix_spawn_file_actions_init()
posix_spawn_file_actions_addchdir("temp")
posix_spawn()
posix_spawn_file_actions_destroy()
Yes, the fact that we implement posix_spawn() on top of fork() makes
this addition comparatively easy to add, because it is very typical to
chdir() in between fork() and exec(), no locking required. It's just
that we need an interface to direct posix_spawn() to do that chdir().
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org