From owner-freebsd-arch@FreeBSD.ORG  Sun Dec  2 13:25:20 2007
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
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 94AF816A46B;
	Sun,  2 Dec 2007 13:25:20 +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 4FEB713C4E5;
	Sun,  2 Dec 2007 13:25:20 +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 1209417106;
	Sun,  2 Dec 2007 13:25:19 +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 lB2DPFJk018720;
	Sun, 2 Dec 2007 13:25:15 GMT (envelope-from phk@critter.freebsd.dk)
To: Andre Oppermann <andre@freebsd.org>
From: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
In-Reply-To: Your message of "Sun, 02 Dec 2007 13:53:18 +0100."
	<4752AABE.6090006@freebsd.org> 
Date: Sun, 02 Dec 2007 13:25:15 +0000
Message-ID: <18719.1196601915@critter.freebsd.dk>
Sender: phk@critter.freebsd.dk
Cc: Attilio Rao <attilio@freebsd.org>, arch@freebsd.org,
	Robert Watson <rwatson@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 <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 02 Dec 2007 13:25:20 -0000

In message <4752AABE.6090006@freebsd.org>, Andre Oppermann writes:

>> 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.

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.

I'm going to exchange that problem for once that is less severe.

My plan is to use non-blocking grabs of the timeouts lock to get
around that race.

When a timeouts timer expires, the thread that services the timeouts
will try to get the lock in a non-blocking fashion, and if it fails,
be put on a queue, to be retried after any other expired timeouts
have had their chance.

That leaves only the question of "how hard to we try to get the lock
with non-blocking means".

The answer to that will depend on how big a problem it is in practice.

Adding timeout_cleanup() as an explicit end of life indicator for
the timeout structure and its lock, makes it possible to use blocking
methods, at high expense, in those rare cases where non-blocking
means keeps failing.

But lets hope we will not need that.

-- 
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.