Date: Wed, 24 Sep 1997 14:27:23 -0600 From: "Justin T. Gibbs" <gibbs@plutotech.com> To: Nate Williams <nate@mt.sri.com> Cc: "Justin T. Gibbs" <gibbs@plutotech.com>, current@FreeBSD.ORG Subject: Re: new timeout routines Message-ID: <199709242027.OAA08517@pluto.plutotech.com> In-Reply-To: Your message of "Wed, 24 Sep 1997 11:19:00 MDT." <199709241719.LAA12880@rocky.mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> It took the first entry off the list. The NetBSD timeout.9 page lists >> this as a bug. > >So, the old behavior (that we've all grown to love now that it's >gone. :) was used for this many years, yet was full of bugs? It could be argued that client code that scheduled multiple timeouts with the same function and argument pointer had the bug in it, but, yes, this "bug" has existed for a long time. >Do hash >collisions not ever occur 'in the current pre-CAM system'? There were one or two of the clients that didn't have proper protection from scheduling the same timeout more than once by mistake, but I fixed that when I put in the new callout interface. The case where you usually see this problem is a driver that schedules a timeout everytime condition X occurs, but it is only required that the timeout expire once even if X occurs multiple times before the timeout expires. So long as untimeouts aren't involved, the only problem with this is that you can consume all the timeouts in the system. If you want to untimeout the event, well, you would lose. Of course this really isn't a "hash collision" as the old untimeout simply traversed the list matching the func and arg pointers to every entry until it found one or the list was exausted. >Nate -- 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?199709242027.OAA08517>