Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 29 Nov 2006 19:45:46 +0000
From:      "Poul-Henning Kamp" <phk@phk.freebsd.dk>
To:        John Baldwin <jhb@freebsd.org>
Cc:        Robert Watson <rwatson@freebsd.org>, freebsd-arch@freebsd.org
Subject:   Re: a proposed callout API 
Message-ID:  <10814.1164829546@critter.freebsd.dk>
In-Reply-To: Your message of "Wed, 29 Nov 2006 13:46:00 EST." <200611291346.01246.jhb@freebsd.org> 

next in thread | previous in thread | raw e-mail | index | archive | help
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.

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

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?10814.1164829546>