Date: Wed, 24 Sep 1997 14:16:05 -0600 From: "Justin T. Gibbs" <gibbs@plutotech.com> To: Julian Elischer <julian@whistle.com> Cc: "Justin T. Gibbs" <gibbs@plutotech.com>, Nate Williams <nate@mt.sri.com>, Terry Lambert <tlambert@primenet.com>, bde@zeta.org.au, current@FreeBSD.ORG Subject: Re: new timeout routines Message-ID: <199709242016.OAA08138@pluto.plutotech.com> In-Reply-To: Your message of "Wed, 24 Sep 1997 11:59:24 PDT." <3429630C.167EB0E7@whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> 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 ===========================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709242016.OAA08138>