Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!longway!std-unix From: jsh@usenix.org (Jeffrey S. Haemer) Newsgroups: comp.std.unix Subject: Standards Update, IEEE 1003.4: Real-time Extensions Message-ID: <465@longway.TIC.COM> Date: 6 Dec 89 19:44:12 GMT Sender: std-unix@longway.TIC.COM Reply-To: std-unix@uunet.uu.net Organization: USENIX Standards Watchdog Committee Lines: 120 Approved: jsq@longway.tic.com (Moderator, John S. Quarterman) From: Jeffrey S. Haemer An Update on UNIX* and C Standards Activities December 1989 USENIX Standards Watchdog Committee Jeffrey S. Haemer, Report Editor IEEE 1003.4: Real-time Extensions Update John Gertwagen reports on the November 13-17, 1989 meeting in Milpitas, CA: Background The P1003.4 Real-time Working Group, began as the /usr/group technical committee on real-time extensions. About two years ago, it was chartered by the IEEE to develop minimum extensions to POSIX to support real-time applications. Over time its scope has expanded, and P1003.4 is now more a set of general interfaces that extend P1003.1 than a specifically real-time standard. Its current work is intended to support not only real-time, but also database, transaction processing, Ada runtime, and networking environments. The group is trying to stay consistent with both the rest of POSIX and other common practice outside the real-time domain. The work is moving quickly. Though we have only been working for two years, we are now on Draft 9 of the proposed standard, and expect to go out for ballot before the end of the year. To help keep up this aggressive schedule. P1003.4 made only a token appearance at the official P1003 meeting in Brussels. The goal of the Milpitas meeting was to get the draft standard ready for balloting. Meeting Summary Most of the interface proposals are now relatively mature, so there was a lot of i-dotting and t-crossing, and (fortunately) little substantive change. The "performance metrics" sections of several interface chapters still need attention, but there has been little initiative in the group to address them, so it looks like the issues will get resolved during balloting. The biggest piece of substantive work was a failed attempt to make the __________ * UNIX is a registered trademark of AT&T in the U.S. and other countries. December 1989 Standards Update IEEE 1003.4: Real-time Extensions - 2 - recently introduced threads proposal clean enough to get into the ballot. The stumbling block is a controversy over how to deal with signals. There are really two, related problems: how to send traditional UNIX/POSIX signals to a multi-threaded process, and how to asynchronously interrupt a thread. Four options have been suggested: delivering signals to a (somehow) privileged thread, per Draft 8; delivering a signal to whichever thread is unlucky enough to run next, a la Mach; delivering the signal to each thread that declares an interest; and ducking the issue by leaving signal semantics undefined. We haven't been able to decide among the options yet; the working group is now split evenly. About half think signal semantics should follow the principle of least surprise, and be fully extended to threads. The other half think each signal should be delivered to a single thread, and there should be a separate, explicit mechanism to let threads communicate with one another. (Personally, I think the full semantics of process signals is extra baggage in the "lightweight" context of threads. I favor delivering signals to a privileged thread -- either the "first" thread or a designated "agent" -- and providing a separate, lightweight interface for asynchronously interrupting threads. On the other hand, I would be happy to see threads signal one another in a way that looks, syntactically and semantically, like inter-process signals. In fact, I think the early, simpler versions of signal() look a lot like what's needed (around V6 or so). I don't care whether the implementation of "process" and "thread" signals is the same underneath or not. That decision should be left to the vendor.) Directions Draft 9 of P1003.4 is being readied for ballot as this is being written and should be distributed by mid-December. With a little luck, balloting will be over by the Summer of '90. Threads is the biggest area of interest in continued work. The threads chapter will be an appendix to Draft 9 and the balloting group will be asked to comment on the threads proposal as if it were being balloted. Unless there is a significant write-in effort, the threads interface will probably be treated as a new work item for P1003.4. Then, if the outstanding issues can be resolved expediently, threads could go to ballot as early as April '90. With the real-time interfaces defined, it looks like the next task of this group will be to create one or more Real-time Application December 1989 Standards Update IEEE 1003.4: Real-time Extensions - 3 - Portability Profiles (RAPPS?) that define how to use the interfaces in important real-time application models. Agreeing on the application models may be harder than agreeing on the interfaces, but we'll see. December 1989 Standards Update IEEE 1003.4: Real-time Extensions Volume-Number: Volume 17, Number 92