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: Thu, 6 Apr 2017 01:45:41 +0200

 This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
 --loBFkqqmbaTL6qMB5HOwdEd3T6KoipVTW
 Content-Type: multipart/mixed; boundary="sjhsCvm4OOlJkfE1ExweiNW4qTjujRatf";
  protected-headers="v1"
 From: Kamil Rytarowski <n54%gmx.com@localhost>
 To: gnats-bugs%NetBSD.org@localhost
 Message-ID: <aa93a804-22df-1f49-2f74-d60140bab630%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>
  <20170405204001.D2D987A27F%mollari.NetBSD.org@localhost>
 In-Reply-To: <20170405204001.D2D987A27F%mollari.NetBSD.org@localhost>
 
 --sjhsCvm4OOlJkfE1ExweiNW4qTjujRatf
 Content-Type: text/plain; charset=windows-1252
 Content-Transfer-Encoding: quoted-printable
 
 On 05.04.2017 22:40, Christos Zoulas wrote:
 > The following reply was made to PR kern/49017; it has been noted by GNA=
 TS.
 >=20
 > From: christos%zoulas.com@localhost (Christos Zoulas)
 > To: gnats-bugs%NetBSD.org@localhost, kern-bug-people%netbsd.org@localhost,=20
 > 	gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
 > Cc:=20
 > Subject: Re: kern/49017: vfork does not suspend all threads
 > Date: Wed, 5 Apr 2017 16:38:32 -0400
 >=20
 >  On Apr 5,  7:35pm, n54%gmx.com@localhost (Kamil Rytarowski) wrote:
 >  -- Subject: Re: kern/49017: vfork does not suspend all threads
 > =20
 >  |  Well vfork(2) is supposed to suspend a parent process.
 >  |  "The parent process is suspended while the child is using its resou=
 rces."
 >  | =20
 >  |   -- vfork(2)
 >  | =20
 >  |  It's out of POSIX so it's rather harsh to dictate behavior change.
 > =20
 >  This wording predates threads and it is not specified in ToG:
 > =20
 >  http://pubs.opengroup.org/onlinepubs/009695399/functions/vfork.html
 > =20
 >  I.e. the suspension of the parent is historical behavior mandated by
 >  implementation convience; it would be difficult to make anything worki=
 ng
 >  reliably if the parent was altering the stack frame the child is curre=
 ntly
 >  executing.
 > =20
 >  |  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.
 > =20
 >  Well, they are not regular processes; linux just does not differentiat=
 e
 >  between threads and processes by re-using the proc structure to descri=
 be
 >  both. In both implementations they end up sharing vmspace, file descri=
 ptors,
 >  etc.
 > =20
 >  |  In ptrace(2) we have two interfaces: PTRACE_FORK and PTRACE_VFORK. =
 The
 >  |  difference between them is only in the point whether the parent pro=
 cess
 >  |  (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)...).
 > =20
 >  That is orthogonal; in fork() the parent is not suspended and ptrace h=
 as
 >  no problem with that. In vfork() only the thread executing vfork() is,=
 
 >  and again ptrace has no problem with that. The semantics if the other
 >  threads should be suspended is the question here. Nico claims that it
 >  is not harmful if they are, and it is actually beneficial. I have come=
 
 >  to the realization that this is true if the child is careful not to
 >  alter the parent data (which has been always the case). The question i=
 s:
 > =20
 >      Can the other threads harm the child or the parent while it is vfo=
 rk()ing?
 > =20
 >  I can't think of a way.
 > =20
 >  |  I thing you might be interested in designing something like _lwp_vf=
 ork().=3D
 > =20
 >  How does this solve the problem? What does _lwp_vfork() fork? Does it =
 create
 >  a new thread? In what process context?
 
 I don't have strong opinions.
 
 If we can ensure that vfork(2) is always safe first, then we can go for
 it... assuming that someone has to do the work.
 
 Regarding _lwp_fork().. I got an impression that optimizing forking is
 today like optimizing thread creation. There is LWP_VFORK in the kernel.
 
 I know that threads and processes are different.. however there are
 still Unices out there without POSIX threads like Minix.
 
 > =20
 >  christos
 > =20
 >=20
 
 
 
 --sjhsCvm4OOlJkfE1ExweiNW4qTjujRatf--
 
 --loBFkqqmbaTL6qMB5HOwdEd3T6KoipVTW
 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
 
 iQIcBAEBCAAGBQJY5YG1AAoJEEuzCOmwLnZsWb8QAJ+J2PgQm5P4Z5RkR8Dh3GqN
 FFVG3P80GOoVpoKyeEtrYca1DQ0KHYNwYQNpfzwrtSECizzEiRQUiakOXn0vGhp9
 z7H8IYhZ59NPJF5Q8NZxncAo+4/jvIhDiJzRqnbXsK2Sv4RWmM9UDIxD6pHr10jV
 rYnty5yItghI1RHpCMD4pWus63+EmXxV9AqxvxMpzZckJC0LLhAN0Ms7+SpRh2mX
 Vwrl3+r/kKV79eATxSg8jpSDuViPot2pnLFD47zC++VVEc0BeFVBOZJsVGAIJb4r
 0esPXg+ftxq6+3HvLue9gJHy4y9IaZ1vgGLW2xOqJ+s6gBspW1GOOIV1HzCrj76p
 PCvYFN2oKwumNPSMtt3uELdw4zLy0ak9KzZZgrVf98Hv+KCSHwfpxUX9yZ66ipjp
 bQoNP5+AS1vjtySsSAFRBXXkZyLCiyM/pihcm2ymd/1Ayy7tFBtms38M02EYDUeO
 dpWGeK/FdvNL7W/iUM9Pcc6h66W1HUzP4ZkxGUblTqZADlz4InD5BtjtUBc1J6f9
 2NPWwVsMNz3coKKkhOl3cNFdtBOTG/M0lDhcC196WevZkFSKOUuhqaGci8Y9X5hD
 LXm5gsX01tX+cN/z5aWLlUEQW0I8G07FVq7HZuHsUH8fJso6EFd+pVy9HnH3LAG7
 hxJJgfAVOgzdm7LK6Ll3
 =uRNq
 -----END PGP SIGNATURE-----
 
 --loBFkqqmbaTL6qMB5HOwdEd3T6KoipVTW--