Standards Update, IEEE 1003.4: Real-time Extensions

[Jeffrey S. Haemer]

From:  Jeffrey S. Haemer <jsh at usenix.org>


           An Update on UNIX*-Related Standards Activities

                             August, 1990

                 USENIX Standards Watchdog Committee

          Jeffrey S. Haemer <jsh at usenix.org>, Report Editor

IEEE 1003.4: Real-time Extensions

Rick Greer <rick at ism.isc.com> reports on the July 16-20 meeting in
Danvers, Massachusetts:

Most of the action in the July dot four meeting centered around -- you
guessed it -- threads.  The current threads draft (1003.4a) came very
close to going to ballot.  An overwhelming majority of those present
voted to send the draft to ballot, but there were enough complaints
from the dot fourteen people (that's multiprocessing -- MP) about the
scheduling chapter to hold it back for another three months.
Volunteers from dot fourteen have agreed to work on the scheduling
sections so that the draft can go to ballot after the next meeting, in
October.

Actually, dot four voted to send the draft to ballot after that
meeting in any case, and the resolution was worded in such a way that
a consensus would be required to prevent the draft from going to
ballot in October.  Thus, the MP folks have this one final chance to
clean up the stuff that's bothering them -- if it isn't fixed by
October, it will have to be fixed in balloting.  Some of us in dot
fourteen felt the best way to fix the thread scheduling stuff was via
ballot objection anyway.  Unfortunately, the threads balloting group
is now officially closed, and a number of MP people saw this as their
last chance to make a contribution to the threads effort.  The members
of dot fourteen weren't the only ones to be taken by surprise by the
closure of the threads balloting group.  It seems that many felt that
it would be a cold day in hell before threads made it to ballot and
weren't following the progress of dot four all that closely.  [Editor:
I've bet John Gertwagen a beer that threads will finish balloting
before the rest of dot four.  The bet's a long way from being decided,
but I still think I'll get my beer.]

Meanwhile, the ballot resolution process continues for the rest of dot
four, albeit rather slowly.  There are a number of problems here, the
biggest being lack of resources.  In general, people would much rather
argue about threads than deal with the day-to-day grunt work
associated with the IEEE standards process.  [Editor: The meeting will

__________

  * UNIXTM is a Registered Trademark of UNIX System Laboratories in
    the United States and other countries.

August, 1990 Standards Update        IEEE 1003.4: Real-time Extensions


				- 2 -

be in Seattle, Washington.  Go.  Be a resource.] Many of the technical
reviewers have yet to get started on their sections.  Nevertheless,
proposed resolutions to a number of objections were presented and
accepted at the Danvers meeting.

     [Editor: Rick is temporarily unavailable, but Simon Patience of
     the OSF has kindly supplied these examples:

     The resolved objections were taken from the CRB: replacing the
     event mechanism by ``fixed'' signals, replacing the shared memory
     mechanism by mmap() and removing semaphore handles from the file
     system name space.  Replacing events by signals was accepted; no
     problem here.  Adopting mmap() got a mixed reception, partly
     because some people thought you had to take all of mmap(), where
     a subset might suffice.  The final vote on this was not to ask
     the reviewer to adopt mmap(), which may not not satisfy the
     objectors.  I'd guess the balloting group will eventually hold
     sway here!  Finally, the group accepted abandoning the use of
     file descriptors for semaphore handles, but some participants
     wanted to keep semaphore names pathnames.  The reviewer was sent
     off to rethink the implications of this suggestion.  ]

We should be seeing a lot more of this in Seattle.  Similar comments
apply to the real-time profile (AEP) work.  The AEP group made more
progress over the last three months than the technical reviewers did,
although even that (the AEP progress) was less than I'd hoped.  We're
expecting our first official AEP draft in October.

August, 1990 Standards Update        IEEE 1003.4: Real-time Extensions

Volume-Number: Volume 21, Number 50