Aren/NetBSD
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Remove

Browse Source 
Users should not depend on the memory sharing semantics of vfork() as
     other ways of speeding up the fork process may be developed in the
     future.

as we are not planning to deprecate vfork. Besides NetBSD's
compatibility policy means we wouldn't change it anyway but introduce
something new.

Add
     Portable applications should not depend on the memory sharing semantics
     of vfork() as implementations exist that implement vfork() as plain
     fork(2).

because this is or used to be a real hazard.

ok christos
This commit is contained in:
dholland 2014-07-18 16:02:50 +00:00
parent efb45e7161
commit 885875e18f
1 changed files with 7 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
lib/libc/sys/vfork.2
View File

@ -1,4 +1,4 @@
.\" $NetBSD: vfork.2,v 1.26 2014/07/18 15:58:51 dholland Exp $
.\" $NetBSD: vfork.2,v 1.27 2014/07/18 16:02:50 dholland Exp $
.\"
.\" Copyright (c) 1980, 1991, 1993
.\" The Regents of the University of California. All rights reserved.
@ -118,10 +118,13 @@ the address space.
The original semantics were reintroduced in
.Nx 1.4 .
.Sh BUGS
Users should not depend on the memory sharing semantics of
Portable applications should not depend on the memory sharing
semantics of
.Fn vfork
as other ways of speeding up the fork process may be developed in
the future.
as implementations exist that implement
.Fn vfork
as plain
.Xr fork 2 .
.Pp
To avoid a possible deadlock situation, processes that are children
in the middle of a