lkml.org 
[lkml]   [1999]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Porting vfork()
Date
From
In message <Pine.LNX.4.04.9901110451590.19839-100000@dahlin.fairplay.no>, 
Torbj
orn Lindgren writes:
+-----
| > | The requirements are basically (paraphrased):
| > | * Don't modify any data other than a variable of type pid_t used to store
| > | the return value from vfork()
| > | * Don't return from the function in which vfork() was called.
| > | * Don't call any functions before successfully calling _exit(),or one of
| > | the exec family of functions.
| >
| > The restrictions are consistent with safety requirements when using a "true"
| > vfork(), so Solaris's implementation is valid. SUS is simply saying that
|
| According to the Solaris man-pages (5.5.1) it suspends the calling thread
| until the child either calls exec*() or exits.
+--->8

Yes, which requires the restrictions above else all hell breaks loose....

I think you still misunderstand the point of the spec: vfork() *can* be
fork(), but you have to follow the restrictions in case it's the hacky
ancient-VAX bug workaround Solaris and a few others use. I get the
impression that SUS disapproves of the hacky implementation, but still
considers it valid (presumably because it wouldn't do to exclude Sun from
SUS compliance).

--
brandon s. allbery [os/2][linux][solaris][japh] allbery@kf8nh.apk.net
system administrator [WAY too many hats] allbery@ece.cmu.edu
carnegie mellon / electrical and computer engineering KF8NH
We are Linux. Resistance is an indication that you missed the point.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.699 / U:0.356 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site