Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 6 Aug 2012 11:25:35 +0300
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Jilles Tjoelker <jilles@stack.nl>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: system() using vfork() or posix_spawn()
Message-ID:  <20120806082535.GI2676@deviant.kiev.zoral.com.ua>
In-Reply-To: <20120805215432.GA28704@stack.nl>
References:  <20120730102408.GA19983@stack.nl> <20120730105303.GU2676@deviant.kiev.zoral.com.ua> <20120805215432.GA28704@stack.nl>

next in thread | previous in thread | raw e-mail | index | archive | help

--AhJ190OLnagu9UvS
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Aug 05, 2012 at 11:54:32PM +0200, Jilles Tjoelker wrote:
> On Mon, Jul 30, 2012 at 01:53:03PM +0300, Konstantin Belousov wrote:
> > On Mon, Jul 30, 2012 at 12:24:08PM +0200, Jilles Tjoelker wrote:
> > > People sometimes use system() from large address spaces where it would
> > > improve performance greatly to use vfork() instead of fork().
>=20
> > > A simple approach is to change fork() to vfork(), although I have not
> > > tried this. It seems safe enough to use sigaction and sigprocmask sys=
tem
> > > calls in the vforked process.
>=20
> > > Alternatively, we can have posix_spawn() do the vfork() with signal
> > > changes. This avoids possible whining from compilers and static
> > > analyzers about using vfork() in system.c. However, I do not like the
> > > tricky code for signals and that it adds lines of code.
>=20
> > > This is lightly tested.
>=20
> > It is interesting to note that for some time our vfork(2) no longer
> > stops the whole forked process (parent), only the forking thread is
> > waiting for the child exit or exec. I am not sure is this point
> > important for system(3), but determined code can notice the difference
> > from the fork->vfork switch.
>=20
> Neither fork nor vfork call thread_single(SINGLE_BOUNDARY), so this is
> not a difference.
It is the difference, because vforked child shares parent address space.

>=20
> Thread singling may be noticeable from a failing execve() (but only in
> the process doing execve()) and in the rare case of rfork() without
> RFPROC.

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.

--AhJ190OLnagu9UvS
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (FreeBSD)

iEYEARECAAYFAlAff38ACgkQC3+MBN1Mb4jB+ACg4tGn73m900YArlOgJJnXXN23
VpEAoMfnQYjoWd4MBo9dz6PCtzqdHyE2
=UYgY
-----END PGP SIGNATURE-----

--AhJ190OLnagu9UvS--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120806082535.GI2676>