Path: utzoo!attcan!uunet!longway!std-unix
From: std-unix@longway.TIC.COM (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update Part 3: 1003.4
Message-ID: <336@longway.TIC.COM>
Date: 11 May 89 15:37:35 GMT
Reply-To: std-unix@uunet.uu.net
Lines: 85
Approved: jsq@longway.tic.com (Moderator, John S. Quarterman)

Standards Update                              Part 3: 1003.4

          An update on UNIX|= Standards Activities
       January 1989 IEEE 1003 Meeting, Ft. Lauderdale

                      Part 3:  1003.4

           Shane P. McCarron, NAPS International

     1003.4 - Real Time Extensions to POSIX

     In the previous report, I reported that the Real-Time
committee was prepared to start mock ballot procedures after
the January meeting.  For those of you who have just tuned
in, a mock ballot is a review process where IEEE formal
ballot rules are used, but the ballot is not conducted by
the IEEE Standards Office.  It is used by some committees as
a means of testing to see whether their draft is ready for
prime time.  Anyway, it appears that there were a few
problems that came up at the last minute, and the
anticipated mock ballot did not happen.

     The main reason for this is that two important
proposals have not reached full concensus within the
committee - Realtime Files and Process Memory Locking.  The
working group felt that these were a little too rough for a
formal review, so an extra three months was taken to get
them into better condition.  The April meeting should
produce a draft for mock ballot.

     Those two issues that prevented the draft from going to
mock ballot also proved to be the most controversial yet.
There was a heated debate about the realtime files proposal
because some people wanted parts  of the  proposal  to be
mandatory for all implementations.  The proposal would
require  all  conforming  implementations  to implement  an
Extent Based File System (Among the attributes of an EBFS is
the ability to allocate a file  in  physically contigous
chunks).  This issue went around the table several times but
no final resolution was reached.  The next meeting will
(hopefully) complete these debates.

     The memory locking proposal was reworked  to  allow  an
implementation  that does not "stack" user requests.  In the
original proposal, the user was allowed to stack locks.  The
system  was required to maintain information about each byte

__________

  |= UNIX is a registered trademark of AT&T in the U.S. and
    other countries.

January 1989               - 1 -              Ft. Lauderdale


Standards Update                              Part 3: 1003.4

and the number of times the user locked that byte in memory.
The  draft  6  proposal  will  be  much simpler then the one
released with draft 5.

     The committee also examined what future  topics  should
be covered.  First on the list is a threads (or light weight
process) mechanism. The     realtime  committee  will be
addressing this issue directly after the first draft is
finished (or  before if some working group members get their
way).  There are currently a number of unique interfaces to
threads, and selecting one for a standard should prove to be
a major challenge.

     The USENIX Standards Watchdog Committee contact for
1003.4 is Sol Kavy.  He can be reached at:

          Sol Kavy
          Hewlett-Packard
          19477 Pruneridge
          Cupertino, CA  95014
          sol@hpda.hp.com
          hpda!sol
          +1 (408) 477-6395

January 1989               - 2 -              Ft. Lauderdale


Volume-Number: Volume 16, Number 34