John-Mark Gurney wrote:
> Tim Kientzle wrote this message on Wed, Jun 25, 2003 at 09:51 -0700:
> > Why do exec-ed processes inherit the children of the former
> > process, anyway?  That doesn't entirely sound right to me.
> > Is that behavior mandated by some standard?  If not, this
> > could arguably be considered a kernel bug.  Hmmm...
> 
> Could someone look into this for me?  I don't have any of the standards
> document.  Hmmm. does APUE even talk about this?  It's more of a question
> if exec'd processes inherit children.

The original "Go Solo 2" book says:

        Parent process ID

        An attribute of a new process identifying the parent of
        the process.  The parent process ID of a process is the
        process ID of its creator, for the lifetime of the
        creator.  After the creator's lifetime has ended, the
        parent process ID is the process ID of an implementation-
        dependent system process.

Pretty clear to me they mean "init".  Now the question is whether
or not the creator's lifetime has ended; looking at:

        http://www.opengroup.org/onlinepubs/007904975/functions/exec.html

the answer is not clear; specifically:

        The new process shall inherit at least the following
        attributes from the calling process image:
        [...]
        Process ID
        [...]
        Session membership
        [...]
        Time left until an alarm clock signal (see alarm() )
        [...]
        Interval timers
        [...]

So it seems to me that the answer is a qualified "yes"; the SIGALRM
signals pending expiration of the alarm/itimer interval argue very
strongly that the other pending signals (e.g. SIGCHLD) may also be
inherited.

Probably it's wrong for the program to fork for itself and exec its
child, instead of fork+exec for the child, and remaining itself.

-- Terry
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to