From owner-freebsd-current Wed Sep 24 10:16:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA11702 for current-outgoing; Wed, 24 Sep 1997 10:16:58 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA11681 for ; Wed, 24 Sep 1997 10:16:45 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id LAA24576; Wed, 24 Sep 1997 11:16:27 -0600 (MDT) Message-Id: <199709241716.LAA24576@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Nate Williams cc: "Justin T. Gibbs" , current@freebsd.org Subject: Re: new timeout routines In-reply-to: Your message of "Wed, 24 Sep 1997 11:13:27 MDT." <199709241713.LAA12839@rocky.mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Sep 1997 11:16:15 -0600 From: "Justin T. Gibbs" 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. >Nate -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations ===========================================