From owner-freebsd-arch@FreeBSD.ORG Sun Dec 2 15:16:15 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6630716A417; Sun, 2 Dec 2007 15:16:15 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 21BF613C47E; Sun, 2 Dec 2007 15:16:15 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 1D0BD17105; Sun, 2 Dec 2007 15:16:13 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id lB2FGDLK019296; Sun, 2 Dec 2007 15:16:13 GMT (envelope-from phk@critter.freebsd.dk) To: Andre Oppermann From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 02 Dec 2007 14:55:43 +0100." <4752B95F.20308@freebsd.org> Date: Sun, 02 Dec 2007 15:16:13 +0000 Message-ID: <19295.1196608573@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Attilio Rao , arch@freebsd.org, Robert Watson Subject: Re: New "timeout" api, to replace callout X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2007 15:16:15 -0000 In message <4752B95F.20308@freebsd.org>, Andre Oppermann writes: >> The trouble arises because the current callout implementation will >> try to sleep on the timeouts lock, and once it does that, you cannot >> cancel it any more. > >It hurts us big time in the TCP code. I know, that's one of the major inspirations for this work. >In TCP we've got two types of races: > > o Timer expires on active session but source of timer was just > handled (because segment just arrived). To simplify detection of > timer races some generation count passed together with the timer > may be of value. That way I (or the timer code) can easily detect > if this invocation of the callback has become obsolete. You shouldn't need to do that if my schme works, you can just reschedule the timeout, and it will be rescheduled - _also_ if its time has expired and it is ready to run, once its lock gets freed. > o On shutdown we have to get rid of all timers for sure because once > we release the lock it is immediately destroyed and the memory is > freed and cleared. There is no way the timer must even try to look > at the lock again. This is our major problem child in the TCP and > socket lifecycle code. That should also work ok because as long as you hold the lock, you can safely arm, disable or cleanup the timeout. >There is another fine line. When doing a timer cleanup do I get to >know if there is a timeout pending and waiting in the CPU queue? In >other words can timeout_cleanup() tell us with certainty that a timeout >is no longer active and/or pending? This would help us half way. I'm not sure I understand exactly what you ask about here, do you want to know if there are armed timeouts or do you want to know if they expired ? Either way, the info is there... >Other than that is a flag planned saying "try only once" to obtain >the lock? This may help the first race. Though the current TCP >code is not structured to work that way it could move in that direction. More flags is certainly possible, and we can experiment with which. What I'm looking for right now is people telling me "you obviously need a pointer to a X-mas tree in the timeout_foo() function" before I start on the 444 files... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.