From owner-freebsd-arch@FreeBSD.ORG Thu Jan 3 00:21:33 2008 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 BECF916A46C for ; Thu, 3 Jan 2008 00:21:33 +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 1E82213C46E for ; Thu, 3 Jan 2008 00:21:32 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 81981 invoked from network); 2 Jan 2008 23:46:48 -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 Jan 2008 23:46:48 -0000 Message-ID: <477C2A8A.8090604@freebsd.org> Date: Thu, 03 Jan 2008 01:21:30 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Poul-Henning Kamp References: <2223.1199318990@critter.freebsd.dk> In-Reply-To: <2223.1199318990@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 , freebsd-arch@freebsd.org 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: Thu, 03 Jan 2008 00:21:33 -0000 Poul-Henning Kamp wrote: > In message <477C2739.5000902@freebsd.org>, Andre Oppermann writes: >> Poul-Henning Kamp wrote: >>> In message <477C1CF3.6070301@freebsd.org>, Andre Oppermann writes: >>> >>>> I fear we have to go for the latter. Getting a non-sleeping callout >>>> drain seems to be non-trivial. >>> There is a crucial difference between "non-sleeping" and "not sleeping >>> on my lock" that you should be very careful about in this context. >>> >>> Which is your requirement ? >> Calling timeout_drain() must not sleep and not drop the lock in this >> context (while making any pending timeout go away forever). > > Ok, so if the timeouts callback function is running you propose to > do what ? spin until it returns ? As long as the spinning is bounded. Or it may do some magic atomic cmpset to tell the waiting timeout to give up. Which then confirms and timeout_drain then can return in peace. Some (limited?) timeout structure here may be outside of the tcpcb and get Gc'd by the timeout system asynchronously after the drain. I don't have a perfect solution handy. That's why I try to state the requirement and hope the timeout gurus can work out how to do it. ;-) -- Andre