portable way to do nap()

[Stan Switzer]

In article <1988Oct13.233045.18101 at utzoo.uucp>
henry at utzoo.uucp (Henry Spencer) writes:
> In article <10852 at bellcore.bellcore.com>
> sjs at ctt.bellcore.com (Stan Switzer) writes:
> >Nap costs absolutely nothing to provide and provides a useful function
> >which cannot be performed in any other way in Sys V.3.
> 
> Sorry, the cost is not zero, not in the real world.  Especially when AT&T
> is doing it.  However, I personally don't have it in for nap, particularly;
> I just dislike the V.4 policy of "if you ever wanted it, or even if you
> didn't, no matter what it is or how stupid it is, it's in V.4".

I'll concede that the cost is (somewhat greater than zero), and also
that overinclusiveness (non-orthogonality especially) at the system
call level is a sure sign of a bloated design, but I think you'll have
to agree that they're trying to solve a hard problem and that it could
have been worse.

Ideally, they could have made some "tough" choices (anyone else getting
tired of that word?)  BUT...

Brain-damage is in the eyes of the beholder (to mangle a phrase).  The
BSD partisans, and with considerable justification, got pretty cocky
what with their sockets and their select and their wait3 and their
"more" etc, versus AT&T's System V.2 which for the looooongest time
just stood still.  Now, reasonable people can disagree whether V.3
represents a true improvement over BSD, but at least it finally
established some amount of parity between the two worlds.
Unfortunately, we are left with (frequently gratuitous) differences,
and with large quantities of code which has been built to one system
or another.  Today, with hindsight, anyone could design a system that
is better than either BSD or SysV, but this isn't really the point.
The point is who'd buy a system with still more gratuitous
incompatibilities?

So, we have here a classic engineering problem (engineering: applied
compromise).  The task at hand is a bridge from point "A" to point
"B."  Yeah, I want the bridge to be pretty too -- sleek lines, no gaudy
ornamentation and gee-gaws -- but in the real world, this will be a
secondary concern.

It is pretty clear that this has become the "Reagan era of computing"
where everyone wants to consolidate on one programming language, one
operating system, one true system of computing.  The UNIX community is
now facing a totally new reality.  UNIX is no longer the small furry
mammal taunting the slow lumbering dinosaurs.  UNIX is now the status
quo!  Has UNIX been discovered, or has it been found out?  Can UNIX
(without substantial reworking) ever aspire to be more than a time
sharing system?  We live in interesting times indeed!

There are only two alternatives for the immediate future: Find a
reasonable (if not entirely beautiful) way to consolidate upon the
successes of BOTH BSD and Sys V (Oops! almost forgot POSIX and XJ311,
and /usr/group, and OSF, and ...).  Or, come up with something which
represents a quantum leap forward from UNIX (and while you are at it,
you better figure out how to be UNIX compatible too).  As for the
former, it seems that V.4 is about as good as it is going to get.  For
the latter, I'd suggest you take a look at Tanenbaum's Amoeba system
work.  Perhaps Amoeba is the shape of the future.

Stan Switzer		Not quite ready to give up on the Earth.
sjs at ctt.bellcore.com