From owner-freebsd-current  Wed Sep 24 10:19:08 1997
Return-Path: <owner-freebsd-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id KAA11883
          for current-outgoing; Wed, 24 Sep 1997 10:19:08 -0700 (PDT)
Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA11865
          for <current@freebsd.org>; Wed, 24 Sep 1997 10:19:03 -0700 (PDT)
Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100])
	by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id LAA01794;
	Wed, 24 Sep 1997 11:19:01 -0600 (MDT)
Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id LAA12880; Wed, 24 Sep 1997 11:19:00 -0600 (MDT)
Date: Wed, 24 Sep 1997 11:19:00 -0600 (MDT)
Message-Id: <199709241719.LAA12880@rocky.mt.sri.com>
From: Nate Williams <nate@mt.sri.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: "Justin T. Gibbs" <gibbs@plutotech.com>
Cc: Nate Williams <nate@mt.sri.com>, current@freebsd.org
Subject: Re: new timeout routines 
In-Reply-To: <199709241716.LAA24576@pluto.plutotech.com>
References: <199709241713.LAA12839@rocky.mt.sri.com>
	<199709241716.LAA24576@pluto.plutotech.com>
X-Mailer: VM 6.29 under 19.15 XEmacs Lucid
Sender: owner-freebsd-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> >> So you assume that regardless of what pointers the client gives you,
> >> even if they give you the same pair twice without an intervening 
> >> expiration or untimeout call, that there will be no collisions in
> >> the hash table?
> >
> >How did the original code in untimeout() determine what to pull off the
> >table?  Obviously there is enough information in the untimeout() call to
> >uniquely determine which entry to use, and that same information was
> >used in timeout(), so we must be able to build a perfect hash function.
> 
> It took the first entry off the list.  The NetBSD timeout.9 page lists
> this as a bug.

So, the old behavior (that we've all grown to love now that it's
gone. :) was used for this many years, yet was full of bugs?  Do hash
collisions not ever occur 'in the current pre-CAM system'?


Nate