From owner-freebsd-arch@FreeBSD.ORG Sun Dec 2 12:53:14 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 8220F16A419 for ; Sun, 2 Dec 2007 12:53:14 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id DFC4013C46E for ; Sun, 2 Dec 2007 12:53:13 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 16491 invoked from network); 2 Dec 2007 12:24:21 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 2 Dec 2007 12:24:21 -0000 Message-ID: <4752AABE.6090006@freebsd.org> Date: Sun, 02 Dec 2007 13:53:18 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: Poul-Henning Kamp References: <18378.1196596684@critter.freebsd.dk> In-Reply-To: <18378.1196596684@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 12:53:14 -0000 Poul-Henning Kamp wrote: > In message <4752998A.9030007@freebsd.org>, Andre Oppermann writes: >> o TCP puts the timer into an allocated structure and upon close of the >> session it has to be deallocated including stopping of all currently >> running timers. >> [...] >> -> The timer facility should provide an atomic stop/remove call >> that prevent any further callbacks upon return. It should not >> do a 'drain' where the callback may be run anyway. >> Note: We hold the lock the callback would have to obtain. > > It is my intent, that the implementation behind the new API will > only ever grab the specified lock when it calls the timeout function. This is the same for the current one and pretty much a given. > When you do a timeout_disable() or timeout_cleanup() you will be > sleeping on a mutex internal to the implementation, if the timeout > is currently executing. This is the problematic part. We can't sleep in TCP when cleaning up the timer. We're not always called from userland but from interrupt context. And when calling the cleanup we currently hold the lock the callout wants to obtain. We can't drop it either as the race would be back again. What you describe here is the equivalent of callout_ drain(). This is unfortunately unworkable in TCP's context. The callout has to go away even if it is already pending and waiting on the lock. Maybe that can only be solved by a flag in the lock saying "give up and go away". -- Andre