From owner-freebsd-arch@FreeBSD.ORG  Sun Jan 25 23:42:47 2004
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id BC1B616A4CE
	for <arch@freebsd.org>; Sun, 25 Jan 2004 23:42:47 -0800 (PST)
Received: from relay.pair.com (relay.pair.com [209.68.1.20])
	by mx1.FreeBSD.org (Postfix) with SMTP id 709C143D1D
	for <arch@freebsd.org>; Sun, 25 Jan 2004 23:42:46 -0800 (PST)
	(envelope-from silby@silby.com)
Received: (qmail 45331 invoked from network); 26 Jan 2004 07:42:45 -0000
Received: from niwun.pair.com (HELO localhost) (209.68.2.70)
  by relay.pair.com with SMTP; 26 Jan 2004 07:42:45 -0000
X-pair-Authenticated: 209.68.2.70
Date: Mon, 26 Jan 2004 01:42:44 -0600 (CST)
From: Mike Silbersack <silby@silby.com>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
In-Reply-To: <62080.1075098867@critter.freebsd.dk>
Message-ID: <20040126013147.A1599@odysseus.silby.com>
References: <62080.1075098867@critter.freebsd.dk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
cc: arch@freebsd.org
Subject: Re: Updating callout_reset
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.1
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: Mon, 26 Jan 2004 07:42:47 -0000


On Mon, 26 Jan 2004, Poul-Henning Kamp wrote:

> No, not timespec.
>
> Timespecs are stupid, slow, clumsy and unhandy and cumbersome.
>
> With a timespec you either need an MPunsafe hack function like
> libevents evConsTime() or a local stack variable.
>
> Make it a 64bit count of nanoseconds instead that way it can be
> used as a literal constant.
>
> It's OK with me if we want to have a function to contain the "*
> 1000000000LL" factor for us, and maybe even convenience functions
> for milli and microseconds.
>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20

Ah, that would work better.  I guess this getting ideas reviewed process
does help. :)

Do we have a preexisting name for the "64bit nanoseconds" type?

Mike "Silby" Silbersack