API explosion (Re: [RFC/RFT] calloutng)

[Ian Lepore]

On Wed, 2012-12-19 at 00:29 +0100, Luigi Rizzo wrote:
> On Tue, Dec 18, 2012 at 04:27:45PM -0700, Ian Lepore wrote:
> > On Tue, 2012-12-18 at 23:58 +0100, Luigi Rizzo wrote:
> > > [top posting for readability;
> > > in summary we were discussing the new callout API trying to avoid
> > > an explosion of methods and arguments while at the same time
> > > supporting the old API and the new one]
> > > (I am also Cc-ing phk as he might have better insight
> > > on the topic).
> > > 
> > > I think the patch you propose is a step in the right direction,
> > > but i still remain concerned by having to pass two bintimes
> > > (by reference, but they should really go by value)
> > > and one 'ticks' value to all these functions.
> > > 
> > > I am also dubious that we need a full 128 bits to specify
> > > the 'precision': there would be absolutely no loss of functionality
> > > if we decided to specify the precision in powers of 2, so a precision
> > > 'k' (signed) means 2^k seconds. This way 8 bits are enough to
> > > represent any precision we want.
> 
> ...
> > I'm not so sure about the 2^k precision.  You speak of seconds, but I
> > would be worrying about sub-second precision in my work.  It would
> > typical to want a 500uS timeout but be willing to late by up to 250uS if
> 
> i said k is signed so negative values represent fractions of a
> second. 2^-128 is pretty short :)
> 
> cheers
> luigi

Ahh, I missed that.  Good enough then!  Hmmm, if that ideas survives
further review, then could precision be encoded in 8 bits of the flags,
eliminating another parm?

-- Ian