Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!cmcl2!husc6!ut-sally!std-unix
From: std-u...@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Job control, windows, streams
Message-ID: <5992@ut-sally.UUCP>
Date: Sat, 11-Oct-86 21:35:31 EDT
Article-I.D.: ut-sally.5992
Posted: Sat Oct 11 21:35:31 1986
Date-Received: Sat, 11-Oct-86 23:59:12 EDT
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Lines: 54
Approved: j...@sally.utexas.edu

From: g...@brl.arpa (VLD/VMB)
Date:     Sat, 11 Oct 86 7:06:31 EDT

The current 1003.1 job control proposal is specifically OPTIONAL for
POSIX-conforming systems, partly at my insistence two meetings back.
The idea is to provide a standard for this feature, even though it is
not universal, simply because many vendors feel pressured to provide
Berkeley-style job control.  I believe H-P already has this in their
SVID-compliant system, HP-UX.  Note that the hooks for this are not
quite the same as in 4BSD, due primarily to System V compatibility
constraints.

Several of the recent 1003.1 RFCs and proposals have been aimed at
those areas where traditional AT&T-supplied UNIX has been perceived
as sufficiently weak that other sources (mostly Berkeley) have come
up with features to fill the gap.  These areas include reliable
signals, extent-based file systems, enhanced terminal handler user
interface, and Berkeley-style job control.  Practically all such
ideas have been iteratively discussed and revised before being added
to the POSIX standard document; some are still not adopted but may be
approved for POSIX within a meeting or two.  (I must commend the
committee members and other corporate staff, from H-P and Sun
particularly, who have invested much time in working out the details
of such proposals.)

I hope that the BSD futures planners seriously consider IEEE 1003
compliance for future releases.  That would greatly help their "VAR"
customers (i.e. system vendors) and UNIX programmers in general.
(We have taken quite a bit of trouble to keep BSD systems in mind
when drafting the 1003.1 POSIX standard.)  AT&T's bone-headed SVR3.0
licensing restrictions have suddenly made POSIX conformance an
attractive alternative to SVID compliance in the commercial marketplace,
and it should be obvious why a neutral industry standard would be well
received by government agencies, not to mention by AT&T's competitors.
Support from Berkeley would mean a lot at this stage.

Streams a la DMR would be terrific; however, please keep in mind that
the 1003 WG is not tasked with designing an ideal operating system,
but rather with standardizing a useful interface to a closely related
family of operating systems.  If we strive for the ideal design before
publishing a standard, it will be too late to do any good, and vendors
won't get their systems to conform very soon if ever.  There is room
for future extensions to the standard (which perhaps could be better
structured for this purpose), and indeed there are real-time, signals,
and shell/utility working groups and subcommittees working on some of
these areas already.

As far as multiplexing goes, one can't reasonably leave that to user
mode even with DMR streams; context switching is too expensive.  We've
been running a version of "mpx" (DMD layer host manager) that uses
select() to multiplex in user mode, and it is noticeably slower than
kernel-mode multiplexing.

Volume-Number: Volume 7, Number 52