From owner-freebsd-current Wed Sep 24 13:16:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA23722 for current-outgoing; Wed, 24 Sep 1997 13:16:56 -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 NAA23714 for ; Wed, 24 Sep 1997 13:16:48 -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 OAA08138; Wed, 24 Sep 1997 14:16:17 -0600 (MDT) Message-Id: <199709242016.OAA08138@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Julian Elischer cc: "Justin T. Gibbs" , Nate Williams , Terry Lambert , bde@zeta.org.au, current@FreeBSD.ORG Subject: Re: new timeout routines In-reply-to: Your message of "Wed, 24 Sep 1997 11:59:24 PDT." <3429630C.167EB0E7@whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Sep 1997 14:16:05 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> The cookie is essentially a direct pointer to the entry that needs to >> be removed. So, removal takes constant time. In your scheme, you need >> to allocate an additional hash table and add a set of links to each >> callout entry so it can live both in the callwheel and in the hash >> table. Then, in untimeout, you must traverse a hash chain of indeterminate >> length in order to find the entry, hence it is no longer a constant time >> operation. This wouldn't be a problem if untimeout wasn't called from >> interrupt contexts, but it is. >> >so what happens if I call untimeout twice? Absolutely nothing. >there is an assumption in a lot of code that untimeout is idempotent >(did I get that right?). It can be called whenever you are recovering >from unknown situations with the sure knowledge that the appropriate >timeout will be removed. And it will. >1/ there is no way to do this without lots of work now. Not true. Read the code and the man page. >2/ old code will break. Nope. >do you check for a NULL pointer? (I have read the paper but not the code >(yet) You should read the code. 8-) -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations ===========================================