From owner-freebsd-current Wed Sep 24 17:24:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA10459 for current-outgoing; Wed, 24 Sep 1997 17:24:22 -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 RAA10454 for ; Wed, 24 Sep 1997 17:24:16 -0700 (PDT) Received: (from tlambert@localhost) by usr03.primenet.com (8.8.5/8.8.5) id RAA03253; Wed, 24 Sep 1997 17:24:09 -0700 (MST) From: Terry Lambert Message-Id: <199709250024.RAA03253@usr03.primenet.com> Subject: Re: new timeout routines To: gibbs@plutotech.com (Justin T. Gibbs) Date: Thu, 25 Sep 1997 00:24:08 +0000 (GMT) Cc: nate@mt.sri.com, gibbs@plutotech.com, current@FreeBSD.ORG In-Reply-To: <199709241716.LAA24576@pluto.plutotech.com> from "Justin T. Gibbs" at Sep 24, 97 11:16:15 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. > > It took the first entry off the list. The NetBSD timeout.9 page lists > this as a bug. The "cure" is worse than the disease, in this case; see my other posting on looking for your curproc. In reality, in the NetBSD code it's not a bug, as long as the interface is called reflexively. This is because there is no kernel preemption to cause it to interleave requests. Requests run either to completion or to blocking. If they block, they are not removed. If they do not block, then they are the head entry. No problems. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.