On 19.12.2012 01:37, 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 :)
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?
Those who tracked the branch could see that actually was our first
approach to handle precision. Unfortunately, it appeared not very
convenient when you need to convert relative precision in percents or
fraction of interval to the absolute precision in power of 2. We were
worried that using some ffsll() for it can be inconvenient or expensive.
But since we are now talking about passing relative bintime as an
argument, that may be more viable option. I'll make another try.
Thanks for the input. Pity it didn't happen couple of months ago.
--
Alexander Motin
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
