--hYooF8G/hrfVAmum
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Oct 19, 2007 at 03:06:19AM +0200, Johnny Billquist wrote:
> Andrew Doran skrev:
> >On Thu, Oct 18, 2007 at 11:47:33PM +0200, Joerg Sonnenberger wrote:
> >>On Thu, Oct 18, 2007 at 10:43:11PM +0100, Andrew Doran wrote:
> >
> >	user provides a timeout value
> >	enter timed sleep waiting for a condition to become true
> >	wake up early, find that the condition is still not true
> >	go back to sleep re-using the same timeout value
> >
> >If we pass an absolute wakeup time to the sleep routine then the above w=
ill
> >not sleep longer than requested.
>=20
> The ugly thing about absolute time is that it can be affected by time=20
> changes (like you noted), unless we have a guaranteed monotonically=20
> increasing clock for only this purpose, that can't be "changed". I think=
=20
> it's a rather broken scheme if where you can't sleep for a specified time=
,=20
> and be sure that it will actually be that much time, independent of if th=
e=20
> system time is changed.

I think we'd need (and I think we actually already have or we did have)=20
a monotonic clock for this.

> However, sometimes you also want to sleep until a specific time occurs, i=
n=20
> which an absolute time really is preferrable.
> Heck, you probably really would want both. Can we do that?

Yes. It may clutter the interface and developers would need to think about=
=20
which time they were looking at. Taking wall clock time, adding a=20
constant, and passing it to a call wanting monotime won't work. :-)

Take care,

Bill

--hYooF8G/hrfVAmum
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)

iD8DBQFHGBeJWz+3JHUci9cRAiCUAJ9eHTTRtKvkJdRaTQm+QCKxQV8YZACdE6Kf
koT+2lk91g+71zqBY1w+LW8=
=lDsm
-----END PGP SIGNATURE-----

--hYooF8G/hrfVAmum--