[lkml]   [1999]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Porting vfork()
On Thu, Jan 07, 1999 at 02:07:51PM +1300, Chris Wedgwood wrote:
> On Tue, Jan 05, 1999 at 03:46:11PM -0600, wrote:
> > As of late the "different" vfork() behavior in Linux is appearing
> > as a porting problem more often than expected (by me).
> Specifically, what is breaking?
> Most applications I've seen that use vfork seem to work without any
> changes here....

Agreed. Most are fine, however...

In a proper vfork() implementation, the child shares its parent's address space
(and usurps the parents thread of control) until a call to execve (or exit)
is made. Note that the parent is suspended until the child calls execve
or exit.

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.

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.

IMHO, both of these issues are the result of silly application coding.
(Given that parent thread of control is usurped AND if access to parent
memory is needed then the programmer should have done his/her work prior to
the call to vfork() in the first place!).

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.

Reed H. Petty

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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