Re: kern/49017: vfork does not suspend all threads

[Kamil Rytarowski <n54%gmx.com@localhost>]

The following reply was made to PR kern/49017; it has been noted by GNATS.

From: Kamil Rytarowski <n54%gmx.com@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/49017: vfork does not suspend all threads
Date: Wed, 5 Apr 2017 21:35:03 +0200

 This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
 --9dKGxhHN2jDhmwoBomF2VlDWlkmB7NHmb
 Content-Type: multipart/mixed; boundary="bRWBLgUFq29jGiVIHBEcLfb3l0vIxScq9";
  protected-headers="v1"
 From: Kamil Rytarowski <n54%gmx.com@localhost>
 To: gnats-bugs%NetBSD.org@localhost
 Message-ID: <89c89a59-2ac0-8acc-61ff-f3d1a89298cb%gmx.com@localhost>
 Subject: Re: kern/49017: vfork does not suspend all threads
 References: <pr-kern-49017%gnats.netbsd.org@localhost>
  <20140718155148.475D614B68%quasar.astron.com@localhost>
  <20170405192000.C1F147A2BC%mollari.NetBSD.org@localhost>
 In-Reply-To: <20170405192000.C1F147A2BC%mollari.NetBSD.org@localhost>
 
 --bRWBLgUFq29jGiVIHBEcLfb3l0vIxScq9
 Content-Type: text/plain; charset=windows-1252
 Content-Transfer-Encoding: quoted-printable
 
 On 05.04.2017 21:20, Martin Husemann wrote:
 > The following reply was made to PR kern/49017; it has been noted by GNA=
 TS.
 >=20
 > From: Martin Husemann <martin%duskware.de@localhost>
 > To: gnats-bugs%NetBSD.org@localhost
 > Cc:=20
 > Subject: Re: kern/49017: vfork does not suspend all threads
 > Date: Wed, 5 Apr 2017 21:17:17 +0200
 >=20
 >  On Wed, Apr 05, 2017 at 06:45:01PM +0000, Nico Williams wrote:
 >  >  There are several ways to use vfork() to spawn children in a high-p=
 erformance
 >  >  way:
 >  > =20
 >  >   - First, obviously, in posix_spawn().
 > =20
 >  At leaset in NetBSD posix_spawn() is completely unrelated to vfork().
 >  Noone is suggesting to stop any thread in a process doing posix_spawn(=
 ).
 > =20
 >  Using vfork() in a program with multiple active threads is madness,
 >  posix_spawn() is the only sensible way.
 > =20
 >  Martin
 > =20
 >=20
 
 Well vfork(2) is supposed to suspend a parent process.
 
 "The parent process is suspended while the child is using its resources."=
 
 
  -- vfork(2)
 
 
 It's out of POSIX so it's rather harsh to dictate behavior change.
 
 Also going for your proposal is imho violating thread-process model in
 NetBSD. It's Linux concept to emulate threads with clone(2), while they
 are still regular processes.
 
 In ptrace(2) we have two interfaces: PTRACE_FORK and PTRACE_VFORK. The
 difference between them is only in the point whether the parent process
 (with all threads) has been suspended or not. No matter what the
 original syscall or API was used (clone(2), __clone(2), posix_spwan(2),
 fork(2)...).
 
 I thing you might be interested in designing something like _lwp_vfork().=
 
 
 
 --bRWBLgUFq29jGiVIHBEcLfb3l0vIxScq9--
 
 --9dKGxhHN2jDhmwoBomF2VlDWlkmB7NHmb
 Content-Type: application/pgp-signature; name="signature.asc"
 Content-Description: OpenPGP digital signature
 Content-Disposition: attachment; filename="signature.asc"
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2
 
 iQIcBAEBCAAGBQJY5UbsAAoJEEuzCOmwLnZs/ocP/0uZTFLgXhZCZU0f1e9UoLFq
 0xgpnbl5nJdIMZsgCw7NMDzOiSAQnBFUOGKsI/6KsSJrc8eQtSzRgxlZW7MnFBUb
 QuDl589usGblCoXfInfdQ91kXcqYOJrjyEC6eB62QxfS3+sYsy036zIaFIUGSOiu
 TUxZgs85zw8cw+b8Ll2tt1CeJoG+ooWUFLtl5uuAlKNoP/3k8bKj3E0ZLfPn7BCI
 +Ms8gjGntXVdNGRX3Xs0mHrfF6gaMZIKU/5P6lz8tHr1M7sQXcb0EbkY9y7YBObd
 dXdROxSn8BTGQAXrPfuD6wIxNTkkZ0em/vsn8dxuCToC1k2ePBjklwuQ4daZA5Cq
 d6RdSjxq7fi+EXeYZRrsv0kWhmK4qTDlSOEICRLu0wIdoGkHvZtpMBL7fKDwSAef
 mh2zopBw0bNyOvXBQHeQE17iUeRWdUtXbjy/sn4oXvn5Rz/Kn5PIYq0Qhc+8uZxj
 TtPM08wE0zf3sO7JT+YzOc351bZYeVTWNpqatGEkHUNxoc48V2FeMTumG9gclZBY
 i+1iELDsi1PUtiBkfiMhSFOPNwc+Rc2ZARdWumxjL84UPsLt2Y4Odnac3qsD/Qwq
 Jqevn9QqDtHk++igR11iJPe82Ljz7xMdfzMtc8cqhNCi/i52FZ/6cqD/A37wy52B
 fs8G20B1qKE2ZOFkVWFW
 =vBxX
 -----END PGP SIGNATURE-----
 
 --9dKGxhHN2jDhmwoBomF2VlDWlkmB7NHmb--