a proposed callout API

[John Baldwin]

On Wednesday 29 November 2006 14:45, Poul-Henning Kamp wrote:
> In message <200611291346.01246.jhb at 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