From owner-freebsd-current Wed Sep 24 10:09:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA11078 for current-outgoing; Wed, 24 Sep 1997 10:09:57 -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 KAA11073 for ; Wed, 24 Sep 1997 10:09:49 -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 LAA24417; Wed, 24 Sep 1997 11:09:45 -0600 (MDT) Message-Id: <199709241709.LAA24417@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 10:56:45 MDT." <199709241656.KAA12715@rocky.mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Sep 1997 11:09:33 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> In your scheme, you need >> to allocate an additional hash table > >So far so good. > >> and add a set of links to each >> callout entry so it can live both in the callwheel and in the hash >> table. > >Huh? Why? The hash table contains a direct pointer to the entry which >is the same as the cookie. Then, it's the exact same code used with >the cookie solution, but w/out requiring changes to the code and >drivers. 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? >No traversing the hash chain (assuming a perfect hash, which should be >pretty easy), and things are still constant time. > >Seems pretty obvious/simple to me. It's not obvious to me. Please explain. >Nate > -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations ===========================================