lkml.org 
[lkml]   [1999]   [Jan]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: 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/

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