[lkml]   [2008]   [Oct]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: parent process behaviour to signal after vfork()
    Hi Valdis,

    On Thu, Oct 30, 2008 at 12:38 AM, <> 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.



     \ /
      Last update: 2008-10-30 14:29    [W:0.026 / U:14.396 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site