bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Introduce posix_spawn


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_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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]