Messages in this thread | | | Date | Fri, 8 Jan 1999 13:13:31 -0600 | From | kernel@draper ... | Subject | Re: Porting vfork() |
| |
On Fri, Jan 08, 1999 at 10:04:33AM -0800, Linus Torvalds wrote: > (snipped)
Greetings Linus, et al
Since starting this disussion thread...
I have checked vfork() behavior on HP-UX (B.10.20), AIX (4.2), FreeBSD (2.2.8), and SunOS (5.5.1). Of these in only Solaris and HP-UX does the child share memory with the calling process.
Both Solaris and HP-UX man pages contain strong cautions. Solaris warns that vfork will disappear in the future and HP-UX states:
vfork() differs from fork() only in that the child process can share code and data with the calling process ( parent process). This speeds cloning activity significantly at a risk to the integrity of the parent process if vfork() is misused. ... All HP-UX implementations must provide the entry vfork(), but it is permissible for them to treat it identically to fork. On some implementations the two are not distinguished because the fork() implementation is as efficient as possible.
IMHO, the child modifying a blocked parents address space prior to exec is silly. As a single thread of control exists (the parent is suspended) and memory is shared, whatever work was done in the child prior to exec should be moved to the parent.
As for the race condition, this is a side effect of "child logic prior to exec". Again, that logic belongs in the parent.
I am now of the opinion that we should do nothing. vfork() application code that is misbehaving needs to be fixed. Linux should not follow HP-UX and Solaris direction by tolerating bad vfork() programming practices. Its not a righteous thing to do.
Regards, Reed H. Petty rhp@draper.net
- 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/
| |