Re: FW: [RFC] A more general timeout specification

2005-09-01 Thread Joe Korty
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

Re: FW: [RFC] A more general timeout specification

2005-09-01 Thread Roman Zippel
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

Re: FW: [RFC] A more general timeout specification

2005-09-01 Thread Daniel Walker
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 th

Re: FW: [RFC] A more general timeout specification

2005-09-01 Thread Daniel Walker
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 th

Re: FW: [RFC] A more general timeout specification

2005-09-01 Thread Roman Zippel
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 e

Re: FW: [RFC] A more general timeout specification

2005-09-01 Thread Joe Korty
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 thi

Re: FW: [RFC] A more general timeout specification

2005-09-01 Thread Joe Korty
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 absolute/rela

Re: FW: [RFC] A more general timeout specification

2005-09-01 Thread Joe Korty
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 expe

RE: FW: [RFC] A more general timeout specification

2005-09-01 Thread Roman Zippel
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 clo

RE: FW: [RFC] A more general timeout specification

2005-09-01 Thread Perez-Gonzalez, Inaky
>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, comm

RE: FW: [RFC] A more general timeout specification

2005-09-01 Thread Roman Zippel
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?

RE: FW: [RFC] A more general timeout specification

2005-09-01 Thread Roman Zippel
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 examp

RE: FW: [RFC] A more general timeout specification

2005-08-31 Thread Daniel Walker
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? Ar

RE: FW: [RFC] A more general timeout specification

2005-08-31 Thread Perez-Gonzalez, Inaky
>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 >>

RE: FW: [RFC] A more general timeout specification

2005-08-31 Thread Roman Zippel
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 u

RE: FW: [RFC] A more general timeout specification

2005-08-31 Thread Perez-Gonzalez, Inaky
>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 time

RE: FW: [RFC] A more general timeout specification

2005-08-31 Thread Perez-Gonzalez, Inaky
>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 >>

Re: FW: [RFC] A more general timeout specification

2005-08-31 Thread Christopher Friesen
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 r

RE: FW: [RFC] A more general timeout specification

2005-08-31 Thread Roman Zippel
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. In

RE: FW: [RFC] A more general timeout specification

2005-08-31 Thread Perez-Gonzalez, Inaky
>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

RE: FW: [RFC] A more general timeout specification

2005-08-31 Thread Perez-Gonzalez, Inaky
>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; >>

Re: FW: [RFC] A more general timeout specification

2005-08-31 Thread Roman Zippel
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*

Re: FW: [RFC] A more general timeout specification

2005-08-31 Thread Christopher Friesen
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 h

Re: FW: [RFC] A more general timeout specification

2005-08-31 Thread Joe Korty
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' for

Re: FW: [RFC] A more general timeout specification

2005-08-31 Thread Christopher Friesen
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 th

Re: FW: [RFC] A more general timeout specification

2005-08-31 Thread Joe Korty
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

RE: FW: [RFC] A more general timeout specification

2005-08-22 Thread Perez-Gonzalez, Inaky
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. .

Re: FW: [RFC] A more general timeout specification

2005-08-22 Thread john stultz
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