Messages in this thread | | | Date | Thu, 30 Oct 2008 08:24:44 -0500 | From | "Michael Kerrisk" <> | Subject | Re: parent process behaviour to signal after vfork() |
| |
Hi Valdis,
On Thu, Oct 30, 2008 at 12:38 AM, <Valdis.Kletnieks@vt.edu> wrote: > On Wed, 29 Oct 2008 08:17:36 CDT, Michael Kerrisk said: > >> diff --git a/man2/vfork.2 b/man2/vfork.2 >> index 55044ad..8a7ed50 100644 >> --- a/man2/vfork.2 >> +++ b/man2/vfork.2 >> @@ -94,7 +94,10 @@ but may call >> .PP >> Signal handlers are inherited, but not shared. >> Signals to the parent >> -arrive after the child releases the parent's memory. >> +arrive after the child releases the parent's memory (i.e., after the child calls >> +.BR _exit (2) >> +or >> +.BR execve (2)). > > OK, I'll bite - when is the parent's memory released if the child doesn't > depart by calling _exit() or execve(), but manages to get killed by an > unhandled signal or the OOM killer or similar?
Yes, thanks for catching that. The wording really should say, until the child does execve(2) or it terminates.
> (That's the generic problem with adding itemized lists to an explanation - it's > rarely clear if the list is an exhaustive list, or a non-complete list of > examples. Note how often we have flame wars regarding which EQUUX should be > returned in a corner case that hinge on whether Posix says "Only FOO, BAR, > and BAZ can be returned" or "FOO, BAR, BAZ are among the errors that can be > returned")
I agree that this is sometime true, but examples need to be looked at on a case-by-case basis. Sometimes using deliberately vague language is appropriate. But sometimes, the solution is just better, more precise language, and I think that's the case here. For man-pages-3.13, I applied the patch below.
Cheers,
Michael
| |