From owner-cvs-all Tue Nov 13 14:45:20 2001 Delivered-To: cvs-all@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id A254637B405; Tue, 13 Nov 2001 14:45:13 -0800 (PST) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id OAA60336; Tue, 13 Nov 2001 14:35:12 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id fADMZBj59293; Tue, 13 Nov 2001 14:35:11 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200111132235.fADMZBj59293@arch20m.dellroad.org> Subject: Re: cvs commit: src/sys/kern kern_timeout.c src/sys/sys callout. In-Reply-To: "from John Baldwin at Nov 13, 2001 02:22:46 pm" To: John Baldwin Date: Tue, 13 Nov 2001 14:35:11 -0800 (PST) Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG John Baldwin writes: > >> > MFC: Change callout_stop() to return an integer. > >> > >> ?? Is this needed for something in 4.x? The only thing it is used for in > >> 5.x > >> is to work around a really obscure race involving the endtsleep() timeout. > > > > Yes, at least I think so.. :-) > > > > The problem I am trying to solve is: suppose you have some object > > (blob of memory) with a reference count. You only free the object > > when the ref count goes to zero. > > > > If you do a callout_reset() using the object as the handler > > argument, obviously you'd want to add a reference. When your > > handler eventually gets invoked, you want to remove a reference. > > > > Now what if you call callout_stop()? That functions does not > > guarantee that your handler won't be called -- because your > > event might have been dequeued and just about to be called, > > but hasn't actually been called yet. Therefore, you don't know > > whether to decrement the reference count or not, unless you > > have some indication from callout_stop() about whether the > > funny case of dequeued-but-not-handled-yet has happened or not. > > > > My analysis may be incorrect, in which case I would love for > > someone to explain all this to me because it seems pretty subtle. > > Yes, it is useful in this case. However, all this tells you is that the > handler has been dequeued. You don't know if it has already run or will run > in the future however. Determining that is another trick. For the Right.. easy to do using a flag bit in the structure/object. > endtsleep race, we use the TDF_TIMOFAIL flag to test this. In the case you > describe I think it is simpler though as the timeout will always do the > decrement, so you simply don't decrement if the callout_stop() fails. Exactly.. Thanks, -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message