From owner-freebsd-current Wed Jul 10 12:20:28 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED85237B401; Wed, 10 Jul 2002 12:20:17 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A64843E65; Wed, 10 Jul 2002 12:20:17 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020710192017.SGVB24728.rwcrmhc51.attbi.com@InterJet.elischer.org>; Wed, 10 Jul 2002 19:20:17 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA41786; Wed, 10 Jul 2002 12:03:46 -0700 (PDT) Date: Wed, 10 Jul 2002 12:03:44 -0700 (PDT) From: Julian Elischer To: Archie Cobbs Cc: John Baldwin , freebsd-current@FreeBSD.org, David Xu Subject: Re: Timeout and SMP race In-Reply-To: <200207101616.g6AGG4T28124@arch20m.dellroad.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 10 Jul 2002, Archie Cobbs wrote: > John Baldwin writes: > > It is the same problem. What we do is change callout_stop() to let you know if > > it actually stopped the timeout or not. You then have to use your own locking > > and synchronization in the timeout function and yourself to close the rest of > > the race. > > OK, thanks. > > What do you think of the idea of letting the timer code (optionally) > handle all the locking and race conditions? > > Even with callout_stop() returning 1 or 0, there still is *lots* > of complexity required on the client side, especially when the > object associated with the timer can be freed after stopping the > timer, and you can have the same timer stopped and then restarted > (which means that if you can't reliably stop the timer before > starting another one, you can get an early timeout due to a previously > not-stopped timer (which you have to check for (which is not trivial))). > > I beg you to look at netgraph/ng_pptpgre.c for an example of the > gymnastics required. For example, you can't just use the object (in > this case a netgraph node) as the void * argument to the timeout > routine: you have to malloc() a separate structure containing just > a pointer to the object, and then in the object itself have a pointer > back to the malloc()'d structure. This is necessary so you can > differentiate a "real" timer timeout from the previously stopped (but > not really stopped) timer timeout if the timer was then restarted. > > In my experience, if the timer routines handle the locking life gets > MUCH simpler for everyone else. I certainly agree that mayb ewe should look at supplying support in teh timeout code for handling this race.. I've had my mind bent by it a few too many times, and I'm starting to think "There's got to be a better way" Archie.. can you pu tup a strawman proposal for the API chenge needed? > > -Archie > > __________________________________________________________________________ > Archie Cobbs * Packet Design * http://www.packetdesign.com > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message