Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uunet!usenix!std-unix From: jsh@usenix.org (Jeffrey S. Haemer) Newsgroups: comp.std.unix Subject: Standards Update, IEEE 1003.4: Real-time Extensions Message-ID: <448@usenix.ORG> Date: 22 Aug 90 16:09:13 GMT Sender: std-unix@usenix.ORG Reply-To: std-unix@uunet.uu.net Organization: USENIX Standards Watchdog Committee Lines: 91 Approved: jsq@usenix.org (Moderator, John Quarterman) X-Submissions: std-unix@uunet.uu.net From: Jeffrey S. Haemer An Update on UNIX*-Related Standards Activities August, 1990 USENIX Standards Watchdog Committee Jeffrey S. Haemer , Report Editor IEEE 1003.4: Real-time Extensions Rick Greer 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