Messages in this thread | | | From | Matthew Brown <> | Date | Thu, 7 Jan 1999 13:57:11 -0800 (PST) | Subject | Re: Porting vfork() |
| |
kernel@draper.net writes: > Linux aliases vfork() to fork()... problematic in two areas: > > 1) The child receives a new address space. Memory changes made by the > vfork() child are not visible to the parent. > > When the parent expects the child to alter the parent's memory (manipulate > the file descriptor table, modify a global variable, or whatever) prior to > the execve... a current address space porting problem arises.
Every man page and document about vfork() I've ever seen has told people to never rely on this behaviour. I don't think we need to encourage such brokenness.
> 2) When the parent can no longer assume (and requires) that the child will > be dispatched and execve prior to the parent receiving control back from > vfork()... a subtle race condition porting problem arises.
The race condition would exist anyway. As far as I can see, there aren't many assumptions that would be useful here; even in vfork(), the execve() would have happened, but the child might not have executed a single instruction yet.
> My intent in this thread was to gage the vfork() impact. It makes no sense > to commit time developing a kernel solution if only a very few applications > have such silly dependencies.
I don't think we should waste our time on this. Very few applications will have dependencies on this behavior, and if they do they're probably already buggy. I can't see that fixing them is all that hard, either.
If I'm wrong, I'll be very surprised; give examples of where not supporting vfork() hurts us! Also, most of them will only be assuming that if there's a vfork(), it works; since not all unices have vfork(), portable applications won't rely on it.
-Matt
-- Matthew J. Brown --- Senior Technical Engineer --- SBC Interactive Work email: mbrown@smartpages.com - Personal email: morven@byz.org Phone: (626) 585-9765 Pager: 9121311@skytel.com or (888) 912-1311
- 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/
| |