From owner-freebsd-current  Wed Sep 24 09:56:34 1997
Return-Path: <owner-freebsd-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id JAA10299
          for current-outgoing; Wed, 24 Sep 1997 09:56:34 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA10293
          for <current@freebsd.org>; Wed, 24 Sep 1997 09:56:31 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id CAA03721; Thu, 25 Sep 1997 02:53:40 +1000
Date: Thu, 25 Sep 1997 02:53:40 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199709241653.CAA03721@godzilla.zeta.org.au>
To: gibbs@plutotech.com, nate@mt.sri.com
Subject: Re: new timeout routines
Cc: bde@zeta.org.au, current@freebsd.org, julian@whistle.com,
        tlambert@primenet.com
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.

Actually, it could take less space since it wouldn't take any space
for cookies (use a non-chained hash table to take no more space in the
callout table or a chained hash table to give less non-determinacy).

Bruce