From owner-freebsd-arch@FreeBSD.ORG Wed Nov 29 21:55:34 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F00D216A415; Wed, 29 Nov 2006 21:55:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55EFC43CA2; Wed, 29 Nov 2006 21:55:30 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id kATLtVHP094423; Wed, 29 Nov 2006 16:55:32 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: "Poul-Henning Kamp" Date: Wed, 29 Nov 2006 16:50:51 -0500 User-Agent: KMail/1.9.1 References: <10814.1164829546@critter.freebsd.dk> In-Reply-To: <10814.1164829546@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611291650.51782.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 29 Nov 2006 16:55:32 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2259/Wed Nov 29 14:28:42 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Robert Watson , freebsd-arch@freebsd.org Subject: Re: a proposed callout API 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: Wed, 29 Nov 2006 21:55:35 -0000 On Wednesday 29 November 2006 14:45, Poul-Henning Kamp wrote: > In message <200611291346.01246.jhb@freebsd.org>, John Baldwin writes: > > >Different APIs would be fine. IIRC, that's how Darwin does it. With the > >tick_t idea, you could easily have: > > > >tick_t relative_wakeup(ulong nsec) > >tick_t absolute_wakeup(struct timeval *tv) (or something else, etc.) > > I really do not want to encode the rel/abs aspect in the tick_t. > > I want it marked up directly in the flags passed which kind of behaviour > the code wants. Hmm, I guess that depends on what you consider tick_t to be. I was thinking of it as an abstract type for a deadline, and that absolute and relative are sort of like subclasses of that. Doing it that way allows you to defer on absolute times rather than requiring whole new APIs. I assume you mean passing a different flag to msleep(), cv_*(), sema_wait(), lockmgr(), etc. that all take 'int timo'? If you allow it to be encoded into the tick_t, then adding support for it just requires a new function to generate a tick_t object and the consuming code has to learn how to handle it, but all the in-between stuff doesn't care and doesn't have to know. > >walltime timeouts (such as for TCP as Poul-Henning mentioned). I like tick_t, > >I just want to make sure we change foosleep() to use it as well, and wanted to > >raise the idea of relative vs absolute deadlines. > > Agreed, foosleep() should take tick_t as well. > > I propose you and I write up the new API in detail and then present > that document here on arch@ at a latter date. > > Is that OK with you ? Sure. -- John Baldwin