Subject: Re: settimeofday() versus interval tim{ers,ing}
To: None <tech-kern@NetBSD.ORG>
From: Ty Sarna <tsarna@endicor.com>
List: tech-kern
Date: 10/04/1996 13:39:47
In article <199610041027.GAA09564@Collatz.McRCIM.McGill.EDU>,
der Mouse  <mouse@Holo.Rodents.Montreal.QC.CA> wrote:
> This leads into another reason why ITIMER_ABSOLUTE isn't a complete
> solution: it doesn't address the desire to pass an absolute time as the
> fifth argument to select().  The only real solution I see to _that_ is
> to add a third field to a struct timeval, specifying whether it's
> absolute or relative.  But of course doing that breaks both source (and
> binary, unless you renumber a handful of syscalls) compatability.
> Sigh.  As well as compatability with the rest of the known universe.
> Double sigh.  I guess the only even semi-workable thing to do is to
> provide an abstime_select() call.  Yech.

Or, do it how it should have been done all along, and make timing a
device driver, so one would select on a time descriptor. Then you
don't even *need* the bloody time argument to select.

O, how I wish Unix had a sane event system.  Want to wait for a signal?
pause().  A pipe? select().  Time? select().  Or alarm() and pause(),
but either way you an only have one outstanding timer.  Message port?
msgrcv().  Want to wait on a signal and a pipe and a couple timers and a
message port and bid asynchronously on a semaphore? Bwahahahaha.

The Amiga exec got it right. You want to wait on any or all of the
above, and more? You call Wait(). Period.

This has been a "unix sucks" rant. We now return you to your regular
mailing list.