From owner-freebsd-current Wed Sep 24 09:11:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA07345 for current-outgoing; Wed, 24 Sep 1997 09:11: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 JAA07337 for ; Wed, 24 Sep 1997 09:11: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 KAA22907; Wed, 24 Sep 1997 10:11:13 -0600 (MDT) Message-Id: <199709241611.KAA22907@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Nate Williams cc: Terry Lambert , julian@whistle.com, gibbs@plutotech.com, bde@zeta.org.au, current@freebsd.org Subject: Re: new timeout routines In-reply-to: Your message of "Wed, 24 Sep 1997 09:23:14 MDT." <199709241523.JAA12165@rocky.mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Sep 1997 10:11:01 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Build a hash list that uses the (fn, args) parameter at timeout time >(which is what the result of the cookie is), and then get to the timeout >via hashing back on this with untimeout(fn, args). No need for the >drivers to hold onto the cookie, since you have all the necessary >information. No-one said this wasn't possible. It just takes additional space and makes untimeout's running time non-deterministic. I decided it was an unacceptable tradeoff. >Nate -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations ===========================================