Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!gorodish!guy
From: guy@gorodish.Sun.COM (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: Bug (??) in BSD real itimer -- doesn' propogate across forks.
Message-ID: <40462@sun.uucp>
Date: 29 Jan 88 19:29:09 GMT
References: <1436@quacky.mips.COM>
Sender: news@sun.uucp
Distribution: all
Lines: 32

> This looks on purpose, but it may have been an incorrect fix added to
> make getitimer() reflect that fact that the real timer wasn't getting
> propogated.

No.  I strongly suspect it was done on purpose.

A set of V7 source around here indicates that the "alarm()" timer was, in fact,
cleared on a "fork()"; this source is not from the original AT&T tape, though,
so I don't know that it was cleared in vanilla V7.

It is *definitely* done this way in S5; from the "fork" manual page for S5R3:

	The child process differs from the parent process in the following
	ways:

	     The child process's "utime", "stime", "cutime", and "cstime"
	     are set to 0.  The time left until an alarm clock signal is
	     reset to 0.

(The S5R2 manual page claims that the alarm clock value is inherited.  The S5R2
*code* claims that it isn't: "newproc" in "slp.c" clears "p_clktim" for the
child process.  The same is true for S5R1, or whatever the S5 release before
S5R2 is supposed to be called; the documentation claims that it is inherited,
but the implementation clears it.)

Furthermore, POSIX draft 12 also indicates that "Pending alarms are cleared for
the child process."

It's not a bug; don't change it.
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com