From owner-freebsd-current Wed Sep 24 17:22:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA10319 for current-outgoing; Wed, 24 Sep 1997 17:22:05 -0700 (PDT) Received: from usr03.primenet.com (tlambert@usr03.primenet.com [206.165.6.203]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA10314 for ; Wed, 24 Sep 1997 17:22:00 -0700 (PDT) Received: (from tlambert@localhost) by usr03.primenet.com (8.8.5/8.8.5) id RAA03046; Wed, 24 Sep 1997 17:21:56 -0700 (MST) From: Terry Lambert Message-Id: <199709250021.RAA03046@usr03.primenet.com> Subject: Re: new timeout routines To: nate@mt.sri.com (Nate Williams) Date: Thu, 25 Sep 1997 00:21:55 +0000 (GMT) Cc: gibbs@plutotech.com, nate@mt.sri.com, current@FreeBSD.ORG In-Reply-To: <199709241713.LAA12839@rocky.mt.sri.com> from "Nate Williams" at Sep 24, 97 11:13:27 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text 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. A given process can only block on one timeout address at a time; as long as it has a pointer to the curproc, it can traverse the entire list looking for the curproc and be sure that that's the one. It can do the same thing (and not fail) in the case of multiple calls. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.