|
From: | Eric Blake |
Subject: | Re: Introduce posix_spawn |
Date: | Fri, 7 Sep 2018 17:15:13 -0500 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 |
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_spawnWhy 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
[Prev in Thread] | Current Thread | [Next in Thread] |