On Wed, Dec 19, 2012 at 11:00:06AM +, Poul-Henning Kamp wrote:
In message 50d192e8.3020...@freebsd.org, Alexander Motin writes:
Linux uses 32.32 format in their eventtimers code.
(And that is no accident, I know who they got the number from :-)
But if at some point we want to
In message 2012125025.ga46...@stack.nl, Jilles Tjoelker writes:
Either way, such a facility should be layered on top of the callout
facility, which should always run in elapsed time[1] with no attention
paid to what NTPD might do to the UTC estimate.
POSIX specifies functions
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
In message 1355873265.1198.183.ca...@revolution.hippie.lan, Ian Lepore writes
:
On Tue, 2012-12-18 at 23:58 +0100, Luigi Rizzo wrote:
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 is a bad idea, and it
On Wed, Dec 19, 2012 at 1:54 AM, Poul-Henning Kamp p...@phk.freebsd.dk wrote:
In message 1355873265.1198.183.ca...@revolution.hippie.lan, Ian Lepore
writes
:
On Tue, 2012-12-18 at 23:58 +0100, Luigi Rizzo wrote:
I'm not so sure about the 2^k precision. You speak of seconds, but I
On 19.12.2012 12:03, Davide Italiano wrote:
On Wed, Dec 19, 2012 at 1:54 AM, Poul-Henning Kamp p...@phk.freebsd.dk wrote:
In message 1355873265.1198.183.ca...@revolution.hippie.lan, Ian Lepore writes
:
On Tue, 2012-12-18 at 23:58 +0100, Luigi Rizzo wrote:
I'm not so sure about the
In message CACYV=-eg542ihm9kfujpvczzra4tqepebva8rzt1yohncgf...@mail.gmail.com
, Davide Italiano writes:
Right now -- the precision is specified in 'bintime', which is a binary number.
It's not 32.32, it's 32.64 or 64.64 depending on the size of time_t in
the specific platform.
And that
In message 50d192e8.3020...@freebsd.org, Alexander Motin writes:
Linux uses 32.32 format in their eventtimers code.
(And that is no accident, I know who they got the number from :-)
But if at some point we want to be able to
handle absolute wall time, [...]
Then you have other
On Wed, 19 Dec 2012, Poul-Henning Kamp wrote:
In message CACYV=-eg542ihm9kfujpvczzra4tqepebva8rzt1yohncgf...@mail.gmail.com
, Davide Italiano writes:
Right now -- the precision is specified in 'bintime', which is a binary number.
It's not 32.32, it's 32.64 or 64.64 depending on the
In message 20121219221518.e1...@besplex.bde.org, Bruce Evans writes:
With this format you can specify callouts 68 years into the future
with quarter nanosecond resolution, and you can trivially and
efficiently compare dur_t's with
if (d1 d2)
This would make a better general
On Wed, Dec 19, 2012 at 4:18 AM, Bruce Evans b...@optusnet.com.au wrote:
On Wed, 19 Dec 2012, Poul-Henning Kamp wrote:
In message
CACYV=-eg542ihm9kfujpvczzra4tqepebva8rzt1yohncgf...@mail.gmail.com
, Davide Italiano writes:
Right now -- the precision is specified in 'bintime',
In message 20121220005706.i1...@besplex.bde.org, Bruce Evans writes:
On Wed, 19 Dec 2012, Poul-Henning Kamp wrote:
Except that for absolute timescales, we're running out of the 32 bits
integer part.
Except 32 bit time_t works until 2106 if it is unsigned.
That's sort of not an
On Wed, 19 Dec 2012, Poul-Henning Kamp wrote:
In message 20121219221518.e1...@besplex.bde.org, Bruce Evans writes:
With this format you can specify callouts 68 years into the future
with quarter nanosecond resolution, and you can trivially and
efficiently compare dur_t's with
On Wed, Dec 19, 2012 at 10:51:48AM +, Poul-Henning Kamp wrote:
In message
CACYV=-eg542ihm9kfujpvczzra4tqepebva8rzt1yohncgf...@mail.gmail.com
, Davide Italiano writes:
Right now -- the precision is specified in 'bintime', which is a binary
number.
It's not 32.32, it's 32.64
In message 20121219150809.ga98...@onelab2.iet.unipi.it, Luigi Rizzo writes:
typedef dur_t int64_t;/* signed for bug catching */
#define DURSEC ((dur_t)1 32)
#define DURMIN (DURSEC * 60)
#define DURMSEC (DURSEC / 1000)
#define
On 19.12.2012 16:20, Bruce Evans wrote:
On Wed, 19 Dec 2012, Davide Italiano wrote:
On Wed, Dec 19, 2012 at 4:18 AM, Bruce Evans b...@optusnet.com.au
wrote:
I would have tried a 32 bit format with a variable named 'ticks'.
Something like:
- ticks = 0. Same meaning as now. No changes in
dropping phk _AT_ onelab2 _DOT_ something from CC as long as it
doesn't seem a valid mail address and I'm annoyed mails bounce back.
On Wed, Dec 19, 2012 at 6:20 AM, Bruce Evans b...@optusnet.com.au wrote:
On Wed, 19 Dec 2012, Davide Italiano wrote:
On Wed, Dec 19, 2012 at 4:18 AM, Bruce Evans
On Wed, 19 Dec 2012, Davide Italiano wrote:
On Wed, Dec 19, 2012 at 4:18 AM, Bruce Evans b...@optusnet.com.au wrote:
I would have tried a 32 bit format with a variable named 'ticks'.
Something like:
- ticks = 0. Same meaning as now. No changes in ABIs or APIs to use
this. The tick
On Wed, 19 Dec 2012, Poul-Henning Kamp wrote:
In message 20121220005706.i1...@besplex.bde.org, Bruce Evans writes:
On Wed, 19 Dec 2012, Poul-Henning Kamp wrote:
Except that for absolute timescales, we're running out of the 32 bits
integer part.
Except 32 bit time_t works until
In message 50d1e0d8.9070...@freebsd.org, Alexander Motin writes:
It would be late to change this after committing. I would definitely
like it to be done earlier to not redo all the tests, but I think we
could convert callout and eventtimers code to 32.32 format in several
days. The
I finally remembered to remove the .it phk :-).
On Wed, 19 Dec 2012, Luigi Rizzo wrote:
On Wed, Dec 19, 2012 at 10:51:48AM +, Poul-Henning Kamp wrote:
...
As I said in my previous email:
typedef dur_t int64_t;/* signed for bug catching */
#define DURSEC
On Mon, Dec 17, 2012 at 11:03:53PM +0200, Alexander Motin wrote:
Hi.
I would instead do the following:
I also don't very like the wide API and want to hear fresh ideas, but
approaches to time measurement there are too different to do what you
are proposing. Main problem is that while
On Tue, Dec 18, 2012 at 06:36:43PM +0100, Luigi Rizzo wrote:
On Mon, Dec 17, 2012 at 11:03:53PM +0200, Alexander Motin wrote:
...
So I believe my proposal would give large simplifications in
the code and lead to a much cleaner implementation of what
you have designed:
1. acknowledge the
On 18.12.2012 19:36, Luigi Rizzo wrote:
On Mon, Dec 17, 2012 at 11:03:53PM +0200, Alexander Motin wrote:
I would instead do the following:
I also don't very like the wide API and want to hear fresh ideas, but
approaches to time measurement there are too different to do what you
are proposing.
On 18.12.2012 20:03, Alexander Motin wrote:
On 18.12.2012 19:36, Luigi Rizzo wrote:
On Mon, Dec 17, 2012 at 11:03:53PM +0200, Alexander Motin wrote:
I would instead do the following:
I also don't very like the wide API and want to hear fresh ideas, but
approaches to time measurement there
[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
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
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
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
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
[again, response to another issue i raised]
On Fri, Dec 14, 2012 at 01:57:36PM +0100, Davide Italiano wrote:
On Fri, Dec 14, 2012 at 7:41 AM, Luigi Rizzo ri...@iet.unipi.it wrote:
...
Finally, a more substantial comment:
- a lot of functions which formerly had only a timo argument
now
Hi.
I would instead do the following:
I also don't very like the wide API and want to hear fresh ideas, but
approaches to time measurement there are too different to do what you
are proposing. Main problem is that while ticks value is relative,
bintime is absolute. It is not easy to make
32 matches
Mail list logo
