system() using vfork() or posix_spawn() and libthr

Konstantin Belousov kostikbel at gmail.com
Thu Aug 9 11:09:06 UTC 2012


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().
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20120809/ac2264f4/attachment.pgp


More information about the freebsd-hackers mailing list