Subject: Re: CVS commit: syssrc/sys/kern
To: Jaromir Dolecek <jdolecek@netbsd.org>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 12/06/2002 12:06:54
On Fri, 6 Dec 2002, Jaromir Dolecek wrote:

> Perry E. Metzger wrote:
> >
> > Jaromir Dolecek <jdolecek@netbsd.org> writes:
> > > It appeared there is no serious objection against the sleep.
> >
> > If you think that our comments to the effect that we don't want it
> > constitute "no objection", then what WOULD be an objection?
>
> Bill & you commented _after_ commit, so obviously I could not
> take it into account _before_ the commit.

That is true, however when did Roland's objection come by? I've lost track
of the exact dates.

> Can you please explain your objection, other than "don't want it"?

Uhm, Roland said it quite well. I'm just reitterating.

1) This is a natural consequence of being a time-share system. As Greg
pointed out, it's been known for a LONG time. The fact that it hasn't been
"fixed" is telling - all the "fixes" folks have come up with aren't.

2) Roland pointed out his system didn't die when the bomb was going off,
so the, "we prevent a death," claims don't seem to hold water.

3) What about Roland's modified bomb? I haven't tried it, but I trust him
when he says that, even when he added a 1 second wait after fork failures
(to simulate your .5 sec wait), it behaved the same. Thus the delay
doesn't stop that bomb; the scope of this fix is limited and easily
circumvented.

> The sleep thing is smart & simple solution to tough problem. I don't
> see how it could cause any new problem. So I currently don't see why
> to not have it there.

4) What happens to "non-rogue" programs that run into this limit? They get
a random 0.5 second delay. That will lead to strange behavior & random
"freezes". ??

Take care,

Bill