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.
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/