From owner-freebsd-current Thu Sep 25 01:48:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA06015 for current-outgoing; Thu, 25 Sep 1997 01:48:08 -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 BAA06010 for ; Thu, 25 Sep 1997 01:48:03 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id SAA05852; Thu, 25 Sep 1997 18:25:38 +1000 Date: Thu, 25 Sep 1997 18:25:38 +1000 From: Bruce Evans Message-Id: <199709250825.SAA05852@godzilla.zeta.org.au> To: julian@whistle.com, nate@mt.sri.com Subject: Re: new timeout routines Cc: bde@zeta.org.au, current@FreeBSD.ORG, gibbs@plutotech.com, tlambert@primenet.com Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> so what happens if I call untimeout twice? > >It does the right thing, since we you 'untimeout the function pointer is >NULL'd out. It's subtler than that. The cookie becomes stale after untimeout(). Stale cookies are not much of a problem since the function pointer (in the object pointed to by the cookie) is "NULL'd out" and the space referenced by the cookie is never freed. If the space is reused, then: case 1: if the space is reused for the same (ftn, arg), then untimeout() with the old cookie will clear the new timeout. This causes the same problems as calling the old version of untimeout() one too many times after a new timeout has been started. Drivers shouldn't do it. case 2: if the space is reused for a different (ftn, arg), then untimeout() withe the old cookie will do nothing. No problem. >> 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. > >According to Justin, the old only removed a timeout with the same >function/arguements, which may/may not have been the right one, if >multiple timeouts with the same function/arguements were created. It made no difference which one was removed, since timeouts with the same (ftn, arg) are equivalent. The problem (if any) was that untimeout() didn't remove all timeouts with the specified (ftn, arg), and it didn't tell you if it did anything, so there was no way to be sure of removing all timeouts without keeping track of the timeouts that you have set. This isn't a real problem. You must keep track of the timeouts that you have set anyway, since setting too many timeouts would exhaust the callout table. The new interface can remove a particular timeout, but this isn't important since timeouts with the same (ftn, arg) are equivalent. It forces you to keep track of timeouts more explicitly to manage the cookies. Code like foo_ch = timeout(foo_handler, 0, hz); in a loop without a corresponding untimeout() is usually wrong because assignment too foo_ch clobbers the previous value. However, it was usually also wrong with the old interface, since it might have exhausted the callout table. OTOH, code like (void)timeout(foo_handler, 0, hz); in a loop without a corresponding untimeout() is correct if the loop only runs once per timeout. Bruce