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

On Tue, Dec 18, 2012 at 04:37:10PM -0700, Ian Lepore wrote:
> 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?

that was also what i wrote later in the message :)

now we should figure out some use for the remaining 22 bits of the flags

cheers
luigi