bug-diffutils
[Top][All Lists]
Advanced

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

Re: [bug-diffutils] Re: new warnings due to use of vfork


From: Eric Blake
Subject: Re: [bug-diffutils] Re: new warnings due to use of vfork
Date: Mon, 24 Jan 2011 17:08:26 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.7

On 01/24/2011 04:37 PM, Paul Eggert wrote:
> vfork has real performance advantages in many applications,
> and we shouldn't reject it merely because it's not specified
> by POSIX (we use a lot of things that aren't in POSIX :-).
> 
> See, for example,
> <http://blog.famzah.net/tag/fork-vfork-performance/>
> which gives an example where vfork+exec is more than
> ten times faster than fork+exec on a Linux kernel.
> And I've seen examples where the disparity is much greater
> than that.

Remember that POSIX 2001 states that 'pid_t vfork(void) { return fork();
}' is a valid implementation, so using vfork() is not always a win.  It
is only on platforms like Linux where a clone()-style syscall exists
where vfork() can be faster than a full fork().

Further, that blog also delved into writing a clone() based solution to
replace vfork() for a Linux-only solution that was more powerful (at
least to the point of making a popen() replacement that didn't suffer
from fork() overhead), then admitted that posix_spawn() is supposed to
be just as fast as the home-grown clone() solution, but with the
benefits of posix_spawn() being standardized.  And since posix_spawn()
has a larger set of portable actions than vfork() of what you can
manipulate before the destination executable finally takes over the
child pid, but can execute with roughly the same speed as vfork() on any
decent platform where vfork() differs from fork(), you can see why POSIX
2008 deprecated vfork() in the first place.

Of course, the gnulib implementation of posix_spawn() is more or less
fork()-based on systems that lack native posix_spawn(), so they won't
benefit from any of the speedups (even if those platforms do have a
faster vfork()).  But on Linux, where posix_spawn() is implemented via
clone() magic, it is indeed faster than fork().  On mingw, where there
is no fork() but where (most of) posix_spawn() can be implemented, you
also have a winning situation.  And on any other system that lacks a
fast posix_spawn(), that system is quickly falling behind in the
standards implementation arena, so it shouldn't matter if our solution
is not as efficient on those platforms.

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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