On Thu, Aug 09, 2012 at 12:56:49PM +0200, Jilles Tjoelker wrote: > On Mon, Aug 06, 2012 at 11:25:35AM +0300, Konstantin Belousov wrote: > > No, other running threads in parent affect vforked child till exec or exit. > > In fact, I would classify this as bug, but not a serious one. > > There are some ugly ways this parallel execution is depended on. If the > vforked child calls sigaction() while another thread is also in > sigaction() for that signal, the vforked child needs to wait for the > other thread to release the lock. > > This uses a per-process lock to synchronize threads in different > processes, which may not work properly. > > If the vforked child is killed (such as by SIGKILL) while holding the > lock, the parent is not killed but its _thr_sigact is damaged. > > These problems could be avoided in libthr by skipping the lock in > _sigaction() if a signal action is being set to SIG_DFL or SIG_IGN and > the old action is not queried. In those cases, _thr_sigact is not > touched so no lock is required. This change also helps applications, > provided they call sigaction() and not signal(). > > Alternatively, posix_spawn() and system() could use the sigaction system > call directly, bypassing libthr (if present). However, this will not > help applications that call vfork() and sigaction() themselves (such as > a shell that wants to implement ... & using vfork()). Third alternative, which seems to be even better, is to restore single-threading of the parent for vfork().
pgpDgz41un713.pgp
Description: PGP signature
