On Thu, Sep 01, 2005 at 04:32:49PM +0200, Roman Zippel wrote:
> On Thu, 1 Sep 2005, Joe Korty wrote:
> > Kernel time sucks. It is just a single clock, it may not have
> > the attributes of the clock that the user really wished to use.
>
> Wrong. The kernel time is simple and effective for
Hi,
On Thu, 1 Sep 2005, Joe Korty wrote:
> On Thu, Sep 01, 2005 at 11:19:51AM +0200, Roman Zippel wrote:
>
> > You still didn't explain what's the point in choosing
> > different clock sources for a _timeout_.
>
> Well, if CLOCK_REALTIME is set forward by a minute,
> timers & timeout specified
On Thu, 2005-09-01 at 16:32 +0200, Roman Zippel wrote:
> Hi,
>
> On Thu, 1 Sep 2005, Joe Korty wrote:
>
> > > When you convert a user time to kernel time you can
> > > automatically validate
> >
> > Kernel time sucks. It is just a single clock, it may not have
> > the attributes of the clock
On Thu, 2005-09-01 at 16:32 +0200, Roman Zippel wrote:
> Hi,
>
> On Thu, 1 Sep 2005, Joe Korty wrote:
>
> > > When you convert a user time to kernel time you can
> > > automatically validate
> >
> > Kernel time sucks. It is just a single clock, it may not have
> > the attributes of the clock
Hi,
On Thu, 1 Sep 2005, Joe Korty wrote:
> > When you convert a user time to kernel time you can
> > automatically validate
>
> Kernel time sucks. It is just a single clock, it may not have
> the attributes of the clock that the user really wished to use.
Wrong. The kernel time is simple and
On Thu, Sep 01, 2005 at 01:50:33AM +0200, Roman Zippel wrote:
> When you convert a user time to kernel time you can
> automatically validate
Kernel time sucks. It is just a single clock, it may not have
the attributes of the clock that the user really wished to use.
Joe
-
To unsubscribe from
On Thu, Sep 01, 2005 at 11:22:32AM +0200, Roman Zippel wrote:
> For a timeout? Please get real.
> If you need more precision, use a dedicated timer API, but don't make the
> general case more complex for the 99.99% of other users.
Struct timeout is just a struct timespec + a bit for
On Thu, Sep 01, 2005 at 11:19:51AM +0200, Roman Zippel wrote:
> You still didn't explain what's the point in choosing
> different clock sources for a _timeout_.
Well, if CLOCK_REALTIME is set forward by a minute,
timers & timeout specified against that clock will expire
a minute earlier than
Hi,
On Thu, 1 Sep 2005, Perez-Gonzalez, Inaky wrote:
> >You still didn't explain what's the point in choosing different clock
> >sources for a _timeout_.
>
> The same reasons that compel to have CLOCK_REALTIME or
> CLOCK_MONOTONIC, for example. Or the need to time out on a
> high resolution
>From: Roman Zippel [mailto:[EMAIL PROTECTED]
>On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:
>
>> Hmm, I cannot think of more ways to specify a timeout than how
>> long I want to wait (relative) or until when (absolute) and which
>> is the reference clock. And they don't seem broken to me,
Hi,
On Wed, 31 Aug 2005, Daniel Walker wrote:
> > What "more versions" are you talking about? When you convert a user time
> > to kernel time you can automatically validate it and later you can use
> > standard kernel APIs, so you don't have to add even more API bloat.
>
> What's kernel time?
Hi,
On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:
> Hmm, I cannot think of more ways to specify a timeout than how
> long I want to wait (relative) or until when (absolute) and which
> is the reference clock. And they don't seem broken to me, common
> sense, in any case. Do you have any
Hi,
On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:
Hmm, I cannot think of more ways to specify a timeout than how
long I want to wait (relative) or until when (absolute) and which
is the reference clock. And they don't seem broken to me, common
sense, in any case. Do you have any
Hi,
On Wed, 31 Aug 2005, Daniel Walker wrote:
What more versions are you talking about? When you convert a user time
to kernel time you can automatically validate it and later you can use
standard kernel APIs, so you don't have to add even more API bloat.
What's kernel time? Are you
Hi,
On Thu, 1 Sep 2005, Perez-Gonzalez, Inaky wrote:
You still didn't explain what's the point in choosing different clock
sources for a _timeout_.
The same reasons that compel to have CLOCK_REALTIME or
CLOCK_MONOTONIC, for example. Or the need to time out on a
high resolution clock.
On Thu, Sep 01, 2005 at 11:19:51AM +0200, Roman Zippel wrote:
You still didn't explain what's the point in choosing
different clock sources for a _timeout_.
Well, if CLOCK_REALTIME is set forward by a minute,
timers timeout specified against that clock will expire
a minute earlier than
On Thu, Sep 01, 2005 at 11:22:32AM +0200, Roman Zippel wrote:
For a timeout? Please get real.
If you need more precision, use a dedicated timer API, but don't make the
general case more complex for the 99.99% of other users.
Struct timeout is just a struct timespec + a bit for
On Thu, Sep 01, 2005 at 01:50:33AM +0200, Roman Zippel wrote:
When you convert a user time to kernel time you can
automatically validate
Kernel time sucks. It is just a single clock, it may not have
the attributes of the clock that the user really wished to use.
Joe
-
To unsubscribe from this
Hi,
On Thu, 1 Sep 2005, Joe Korty wrote:
When you convert a user time to kernel time you can
automatically validate
Kernel time sucks. It is just a single clock, it may not have
the attributes of the clock that the user really wished to use.
Wrong. The kernel time is simple and
On Thu, 2005-09-01 at 16:32 +0200, Roman Zippel wrote:
Hi,
On Thu, 1 Sep 2005, Joe Korty wrote:
When you convert a user time to kernel time you can
automatically validate
Kernel time sucks. It is just a single clock, it may not have
the attributes of the clock that the user
On Thu, 2005-09-01 at 16:32 +0200, Roman Zippel wrote:
Hi,
On Thu, 1 Sep 2005, Joe Korty wrote:
When you convert a user time to kernel time you can
automatically validate
Kernel time sucks. It is just a single clock, it may not have
the attributes of the clock that the user
Hi,
On Thu, 1 Sep 2005, Joe Korty wrote:
On Thu, Sep 01, 2005 at 11:19:51AM +0200, Roman Zippel wrote:
You still didn't explain what's the point in choosing
different clock sources for a _timeout_.
Well, if CLOCK_REALTIME is set forward by a minute,
timers timeout specified against
On Thu, Sep 01, 2005 at 04:32:49PM +0200, Roman Zippel wrote:
On Thu, 1 Sep 2005, Joe Korty wrote:
Kernel time sucks. It is just a single clock, it may not have
the attributes of the clock that the user really wished to use.
Wrong. The kernel time is simple and effective for almost all
On Thu, 2005-09-01 at 01:50 +0200, Roman Zippel wrote:
> What "more versions" are you talking about? When you convert a user time
> to kernel time you can automatically validate it and later you can use
> standard kernel APIs, so you don't have to add even more API bloat.
What's kernel time?
>From: Roman Zippel [mailto:[EMAIL PROTECTED]
>On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:
>
>> I cannot produce (top of my head) any other POSIX API calls that
>> allow you to specify another clock source, but they are there,
>> somewhere. If I am to introduce a new API, I better make it
>>
Hi,
On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:
> I cannot produce (top of my head) any other POSIX API calls that
> allow you to specify another clock source, but they are there,
> somewhere. If I am to introduce a new API, I better make it
> flexible enough so that other subsystems can
>From: Roman Zippel [mailto:[EMAIL PROTECTED]
>On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:
>
>> Usefulness: (see the rationale in the patch), but in a nutshell;
>> most POSIX timeout specs have to be absolute in CLOCK_REALTIME
>> (eg: pthread_mutex_timed_lock()). Current kernel needs the
>From: Christopher Friesen [mailto:[EMAIL PROTECTED]
>Perez-Gonzalez, Inaky wrote:
>
>>>I can get the first sleep. Suppose I oversleep by X nanoseconds. I
>>>wake, and get an opaque timeout back. How do I ask for the new wake
>>>time to be "endtime + INTERVAL"?
>>
>>
>> endtime.ts += INTERVAL
Perez-Gonzalez, Inaky wrote:
I can get the first sleep. Suppose I oversleep by X nanoseconds. I
wake, and get an opaque timeout back. How do I ask for the new wake
time to be "endtime + INTERVAL"?
endtime.ts += INTERVAL
[we all know opaque is relative too]
Heh. Okay, then what are the
Hi,
On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:
> >Why is that needed in a _general_ timeout API? What exactly makes it so
> >useful for everyone and not just more complex for everyone?
>
> Because if a system call gets a timeout specification it needs to
> verify its correctness first.
>From: Christopher Friesen [mailto:[EMAIL PROTECTED]
>Joe Korty wrote:
>
>> The returned timeout struct has a bit used to mark the value as
absolute. Thus
>> the caller treats the returned timeout as a opaque cookie that can be
>> reapplied to the next (or more likely, the to-be restarted)
>From: Roman Zippel [mailto:[EMAIL PROTECTED]
>On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:
>
>> +flags = tp->clock_id & TIMEOUT_FLAGS_MASK;
>> +clock_id = tp->clock_id & TIMEOUT_CLOCK_MASK;
>> +
>> +result = -EINVAL;
>> +if (flags & ~TIMEOUT_RELATIVE)
>> +goto out;
>>
Hi,
On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:
> + flags = tp->clock_id & TIMEOUT_FLAGS_MASK;
> + clock_id = tp->clock_id & TIMEOUT_CLOCK_MASK;
> +
> + result = -EINVAL;
> + if (flags & ~TIMEOUT_RELATIVE)
> + goto out;
> +
> + /* someday, we should support
Joe Korty wrote:
The returned timeout struct has a bit used to mark the value as absolute. Thus
the caller treats the returned timeout as a opaque cookie that can be
reapplied to the next (or more likely, the to-be restarted) timeout.
Okay, endtime is always absolute value of when it should
On Wed, Aug 31, 2005 at 03:20:03PM -0600, Christopher Friesen wrote:
> Perez-Gonzalez, Inaky wrote:
> >In this structure,
> >the user specifies:
> >whether the time is absolute, or relative to 'now'.
>
>
> >Timeout_sleep has a return argument, endtime, which is also in
> >'struct timeout'
Perez-Gonzalez, Inaky wrote:
In this structure,
the user specifies:
whether the time is absolute, or relative to 'now'.
Timeout_sleep has a return argument, endtime, which is also in
'struct timeout' format. If the input time was relative, then
it is converted to absolute and returned
On Wed, Aug 31, 2005 at 01:55:54PM -0700, Perez-Gonzalez, Inaky wrote:
> Hi Andrew
>
> This was developed by Joe Korty <[EMAIL PROTECTED]>, greatly
> enhancing something I had done before, so I am signing it out
> (although Joe should too, Joe?).
The fusyn (robust mutexes) project proposes
On Wed, Aug 31, 2005 at 01:55:54PM -0700, Perez-Gonzalez, Inaky wrote:
Hi Andrew
This was developed by Joe Korty [EMAIL PROTECTED], greatly
enhancing something I had done before, so I am signing it out
(although Joe should too, Joe?).
The fusyn (robust mutexes) project proposes the
Perez-Gonzalez, Inaky wrote:
In this structure,
the user specifies:
whether the time is absolute, or relative to 'now'.
Timeout_sleep has a return argument, endtime, which is also in
'struct timeout' format. If the input time was relative, then
it is converted to absolute and returned
On Wed, Aug 31, 2005 at 03:20:03PM -0600, Christopher Friesen wrote:
Perez-Gonzalez, Inaky wrote:
In this structure,
the user specifies:
whether the time is absolute, or relative to 'now'.
Timeout_sleep has a return argument, endtime, which is also in
'struct timeout' format. If the
Joe Korty wrote:
The returned timeout struct has a bit used to mark the value as absolute. Thus
the caller treats the returned timeout as a opaque cookie that can be
reapplied to the next (or more likely, the to-be restarted) timeout.
Okay, endtime is always absolute value of when it should
Hi,
On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:
+ flags = tp-clock_id TIMEOUT_FLAGS_MASK;
+ clock_id = tp-clock_id TIMEOUT_CLOCK_MASK;
+
+ result = -EINVAL;
+ if (flags ~TIMEOUT_RELATIVE)
+ goto out;
+
+ /* someday, we should support *all* clocks
From: Roman Zippel [mailto:[EMAIL PROTECTED]
On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:
+flags = tp-clock_id TIMEOUT_FLAGS_MASK;
+clock_id = tp-clock_id TIMEOUT_CLOCK_MASK;
+
+result = -EINVAL;
+if (flags ~TIMEOUT_RELATIVE)
+goto out;
+
+/* someday,
From: Christopher Friesen [mailto:[EMAIL PROTECTED]
Joe Korty wrote:
The returned timeout struct has a bit used to mark the value as
absolute. Thus
the caller treats the returned timeout as a opaque cookie that can be
reapplied to the next (or more likely, the to-be restarted) timeout.
Okay,
Hi,
On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:
Why is that needed in a _general_ timeout API? What exactly makes it so
useful for everyone and not just more complex for everyone?
Because if a system call gets a timeout specification it needs to
verify its correctness first. Instead
Perez-Gonzalez, Inaky wrote:
I can get the first sleep. Suppose I oversleep by X nanoseconds. I
wake, and get an opaque timeout back. How do I ask for the new wake
time to be endtime + INTERVAL?
endtime.ts += INTERVAL
[we all know opaque is relative too]
Heh. Okay, then what are the
From: Christopher Friesen [mailto:[EMAIL PROTECTED]
Perez-Gonzalez, Inaky wrote:
I can get the first sleep. Suppose I oversleep by X nanoseconds. I
wake, and get an opaque timeout back. How do I ask for the new wake
time to be endtime + INTERVAL?
endtime.ts += INTERVAL
[we all know opaque
From: Roman Zippel [mailto:[EMAIL PROTECTED]
On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:
Usefulness: (see the rationale in the patch), but in a nutshell;
most POSIX timeout specs have to be absolute in CLOCK_REALTIME
(eg: pthread_mutex_timed_lock()). Current kernel needs the timeout
Hi,
On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:
I cannot produce (top of my head) any other POSIX API calls that
allow you to specify another clock source, but they are there,
somewhere. If I am to introduce a new API, I better make it
flexible enough so that other subsystems can use
From: Roman Zippel [mailto:[EMAIL PROTECTED]
On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:
I cannot produce (top of my head) any other POSIX API calls that
allow you to specify another clock source, but they are there,
somewhere. If I am to introduce a new API, I better make it
flexible
On Thu, 2005-09-01 at 01:50 +0200, Roman Zippel wrote:
What more versions are you talking about? When you convert a user time
to kernel time you can automatically validate it and later you can use
standard kernel APIs, so you don't have to add even more API bloat.
What's kernel time? Are
Hi John
>From: john stultz [mailto:[EMAIL PROTECTED]
>On Thu, 2005-07-28 at 18:52 -0700, Inaky Perez-Gonzalez wrote:
>> The main user of this new inteface is to allow system calls to get
>> time specified in an absolute form (as most of POSIX states) and thus
>> avoid extra time conversion work.
On Thu, 2005-07-28 at 18:52 -0700, Inaky Perez-Gonzalez wrote:
> The main user of this new inteface is to allow system calls to get
> time specified in an absolute form (as most of POSIX states) and thus
> avoid extra time conversion work.
>
> There was a short thread about it, available at
On Thu, 2005-07-28 at 18:52 -0700, Inaky Perez-Gonzalez wrote:
The main user of this new inteface is to allow system calls to get
time specified in an absolute form (as most of POSIX states) and thus
avoid extra time conversion work.
There was a short thread about it, available at google
Hi John
From: john stultz [mailto:[EMAIL PROTECTED]
On Thu, 2005-07-28 at 18:52 -0700, Inaky Perez-Gonzalez wrote:
The main user of this new inteface is to allow system calls to get
time specified in an absolute form (as most of POSIX states) and thus
avoid extra time conversion work.
...
55 matches
Mail list logo
