Usenet 1994 January

home *** CD-ROM | disk | FTP | other *** search

/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / tcos / crf / text0000.txt < prev

Wrap

Internet Message Format | 1990-07-28 | 31.8 KB

From: jsh@ico.isc.com (Jeffrey S. Haemer) [ This is the Common Reference Ballot that was referenced by many balloters in the recent IEEE 1003.4 ballot. -mod ] =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= COMMON REFERENCE BALLOT CHAPTER 3. BINARY SEMAPHORES ---------------------------- OBJECTION 1 Chapter 3 Pages 21-41 Problem: This synchronization facility precludes the use of mechanisms outside the kernel (for example, test-and-set) for optimal performance. On machines where there is shared memory and a test-and-set instruction, you would like the synchronization facility to be able to be implemented completely in shared memory without kernel support. On machines without shared memory, there is already existing mechanism that can be used to construct a binary semaphore facility (for example, the fcntl locking facility). Action: We believe the binary semaphore facility documented in Chapter 3 appears to add no new functionality that cannot be easily constructed from existing interfaces and thus should be removed. The proposed interface should be replaced with a new facility capable of being implemented in shared memory, similar to the 1003.4a synchronization primitives. Ideally this interface should support synchronization between threads in a single process and between processes sharing memory. _________________________________________________________________ CHAPTER 4. PROCESS MEMORY LOCKING. ---------------------------------- OBJECTION 2 Chapter 4 Pages 33-41 Problem: In the current memory locking proposal, the region locks are almost impossible to use in a portable way. The implementation is allowed to lock and unlock any amount of data surrounding the request (including the whole process). Because the call does not return the amount that was actually locked, an application has no way of finding this information. Thus it can issue two lock requests for two disjoint areas, followed by an unlock of the first area and have no idea how much is still locked. It is reasonable for an application to assume that the second area was still locked. The current wording however makes no guarantee of this. A conforming implementation would have to lock some large amount containing both regions and then to unlock that same amount on the first unlock. Thus the second region would no longer be locked. The alternative would be to force all implementations to track the user's requests and maintain information about each page the user locked. This makes things look just like file locking. The only difference is that the file address space is represented by a single kernel data structure (the inode/vnode). The vm system is composed of a set of disjoint kernel data structures even for a single thread. Now suppose process A and B are sharing the same portion of memory (memory mapped files), an implementation would have to maintain locking information on a global system basis to figure out if a page is now pageable. Although this would be done at unlock time and not pageout time, it is still a large set of data structures to maintain. Action: A new interface must be added to determine the locking granularity for that system. A request to (un)lock a region of memory of a specified address and size should return the number of bytes actually (un)locked. The number of bytes will always be a multiple of the granularity for that system. The starting address of the region actually (un)locked will be at the immediately preceding granule boundary unless the requested address was already aligned on a granule boundary. The range actually (un)locked will always encompass the requested range. If the size requested is 0 then no memory is locked. Whether a granule is locked or unlocked is determined by the most recent (un)lock request whose actual range encompassed that granule. As a consequence of these changes, the type parameter is no longer necessary to the memlk() call and so should be deleted. _________________________________________________________________ CHAPTER 5. SHARED MEMORY ------------------------ OBJECTION 3 Chapter 5 Pages 43-59 Lines 1-550 Problem: SVID 3 (System V Release 4.0), OSF AES (OSF/1), Berkeley BSD 4.4, MACH 2.5, ULTRIX, SunOS, HP/UX, etc, all include an (almost) identical definition of mmap() based on the current Sun/Berkeley specification. The implementors and users of these systems all believe there is considerable demand for a generic file-mapping facility such as mmap() provides. We believe the rationale on why mmap() was not used to satisfy the requirement for a shared memory facility to be incorrect, since mmap() is an existing interface that provides the desired functionality. We believe it is better to document the additional "unnecessary parameters" as constant rather than to define a completely new interface. We do not believe a standard should depart from existing practice without sufficient justification. Based on our comments above, we do not believe sufficient justification has been given. Action: We believe there are several actions which will resolve these objections. 1. Provide sufficient justification for a different interface. 2. Adopt the proposal documented in the document "Proposal for Memory Mapped Files" submitted by Sol Kavey at the New Orleans to replace the existing chapter with the mmap() interface. 3. Remove this chapter from this ballot and send this chapter back to the working group for further review. Without at least one of these actions, this ballot remains negative. _________________________________________________________________ CHAPTER 7. ASYNCHRONOUS EVENT NOTIFICATION ------------------------------------------ OBJECTION 4 Chapter 7 Pages 83-116 Problem: The event mechanism is attempting to solve the following apparent deficiencies in the signal mechanism: 1. signals are not queued. 2. there is no way to distinguish between events which generate the same signal. 3. Additional signal numbers are needed for the user defined evt_raise function and to allow user defined signals for the reception of asynchronous events such as I/O and timers. 4. signal delivery cannot be prioritized 5. It is not possible to synchronously wait for specific signals Investigating the signal interfaces provided by Berkeley and System V, we believe there are ways to extend the existing signal mechanism to provide all this functionality without compatibility problems. Action: The chapter should be deleted and replaced with a description of the enhanced signal mechanism. Addressing each point above: 1. System V already has queued signals. The POSIX signal behavior should be similarly strengthened to require queueing for 1003.4 compliant systems. 2. Both Berkeley and System V allow data to be passed to the handler when the signal is delivered via the sigcode parameter. The contents of this parameter should be defined to identify the event. For example, for timer events the sigcode parameter should contain the timer_id and for asynchronous I/O, sigcode should contain the handle. POSIX signals should include passing of sigcode parameter for 1003.4. 3. There is no requirement or rationale for evt_raise which is used as a mechanism for intra-process data passing especially as there are other mechanisms which fill this need. For the delivery of other asynchronous events, more defined signals should be provided. 4. It is already possible to prioritize delivery of signals using the signal mask and disciplined programming. The addition of more defined signals will give finer grain of control over delivery order. 5. An interface similar to the 1003.4a sigwait() function should be provided with the possible addition of a timeout parameter. Addressing these points will unify and therefore simplify the interfaces and solves the problem of defining the interactions between signals and events, for example it is not possible to atomically mask events and signals. _________________________________________________________________ CHAPTER 8. TIMERS ----------------- COMMENT 1 Chapter 8.4.2.4 Page 123 Line 188 Problem: It appears from the description of the error that there is no way for the process to acquire additional timer resources without first freeing some of its existing timer resources. This doesn't appear to be the situation where EAGAIN has been used in the past. Is this really the right error value? _________________________________________________________________ OBJECTION 5 Section 8 Page 117-136 Problem: Asynchronous event notification is used to deliver the timer completion event. (Note. See objection Number # relating to Asynchronous Event Notification chapter requiring event notification to be replaced with enhanced signals.) Action: The proposal for signals (as a replacement for the Asynchronous Event Notification) requires all references to struct event in the calls and data structures in this section to be changed to a signal number to be sent to the requesting process when the timer expires. The timer_id should be passed to the signal handler in the sigcode parameter. If the signal number is 0 then no asynchronous event is sent. _________________________________________________________________ OBJECTION 6 Section 8.4.4 Page 124,125 Line 228-233,260-264 Problem: There is no rationale explaining the difference between resrel() and resabs(). It isn't clear from the existing descriptions why the two are necessary. Action: Provide rationale justifying why two interfaces are necessary or merge the two interfaces into one. _________________________________________________________________ CHAPTER 9. IPC -------------- OBJECTION 7 Section 9.3.1 Page 138 Lines 35-39 Problem: The sender_t has undefined semantics, and is therefore not useful. Since its behavior is not defined, it cannot be used in a conforming program. Action: Remove all references (definition and uses) to fields with type sender_t. Rationale: The only information about the sender which would be useful would be an indication about how to reply to the sender. In this framework that would be a pathname; passing a pathname would be unwieldy and would require all senders to have a receive queue. Furthermore, specifying it as pid_t would be incorrect as per the rationale on page 168-169 lines 1063- 1079. _________________________________________________________________ OBJECTION 8 Section 9.3.1 Page 138 Lines 48 Problem: Asynchronous event notification is used to notify the process of delivery of messages. (Note. See objection Number # relating to Asynchronous Event Notification chapter requiring event notification to be replaced with enhanced signals.) Action: The proposal for signals (as a replacement for the Asynchronous Event Notification) requires all references to events in the calls and data structures in this section to be changed to a signal number to be sent to the requesting process. In particular, replace line 48 with: int msg_signo; The message control block pointer should be passed to the signal handler in the sigcode parameter. If the signal number is 0 then no asynchronous event is sent. _________________________________________________________________ OBJECTION 9 Section 9.3.1 Page 138, 140 Lines 54-57,103-105 Problem: We feel that overloading msg_data with actual message contents is a small optimization that should not be exposed at the interface level. It is possible for the implementation to optimize the transfer of small messages without overloading this field. Also, we feel it is a bad idea to use a pointer to contain data since there is no implied relationship between the size of a pointer and, say, the size of an integer. Action: Remove the facility for sending data as a (void *). Delete Lines 103-105 and all references to MSG_OVERRIDE. _________________________________________________________________ OBJECTION 10 Section 9.3.1 Page 139, 140 Lines 68, 118-125 Comment: The name MQWRAP implies an implementation for throwing away the oldest message. Action: Change the name to something which doesn't imply the implementation. This applies to both MQWRAP and MQNOWRAP. _________________________________________________________________ OBJECTION 11 Section 9.3.1 Page 139 Lines 64-67 Problem: The distinction between mqrsvmsg and mqmaxmsg is unclear (and seems unnecessary). This is also true for mqrsvbytes and mqmaxbytes. Action: Make mqrsvmsg and mqmaxmsg one field. Make mqrsvbytes and mqmaxbytes one field. _________________________________________________________________ COMMENT 2 Section 9.3.1 Page 139 Lines 81 Comment: The word "overwrite" is incorrect. Action: The word should be "discard." The word "overwrite" implies how a message is released. _________________________________________________________________ OBJECTION 12 Section 9.3.1 Page 139 Lines 71-72 Problem: The mqsendwait and mqrcvwait fields cannot be counted on to remain fixed between a reading of the fields and any subsequent action within a program. Therefore, it's not clear what use any program could reliably make of this data. Action: These fields should be removed. _________________________________________________________________ OBJECTION 13 Section 9.3.2 Page 139 Lines 92-94 Problem: There is no justified requirement or rationale for MQ_PERSIST and we can see no immediate use for it. In particular, lines 92-94 can be removed from the standard. We agree with the rationale on lines 1129-1131. Action: Remove lines 92-94 and all references to MQ_PERSIST. _________________________________________________________________ OBJECTION 14 Section 9.3.2 Page 139-140 Lines 95-97, 101-102 Problem: The MSG_COPY and MSG_MOVE flags are unnecessary. The system can distinguish between user-allocated and system-allocated buffers at the time the message is sent. This information can be stored in the message control block by msgalloc(). Action: Delete these lines (95-97 and 101-102). _________________________________________________________________ OBJECTION 15 Section 9.3.2 Page 139-140 Lines 98-100, 109-110, 114-117 Problem: The current draft provides two distinct mechanisms in an attempt to reduce the overhead of copying messages. Unfortunately, the application must choose one of these mechanisms, and there is no portable way to know which is more efficient. We don't believe that it is necessary or desirable to provide two different mechanisms. The MSG_USE facility is the more complex of the two, since it requires additional synchronization (to know when to deallocate the buffer). It also complicates close of a queue and abnormal process termination. We believe it is more desirable to use system-allocated buffers (provided by msgalloc()) than to use a mechanism requiring the system to manipulate user-allocated buffers (cross-address space manipulation). Action: Delete Lines 98-100. Delete all references to MSG_USE. Delete all references to MSG_WAIT and MSG_NOWAIT. _________________________________________________________________ COMMENT 3 Section 9.4 Page 141 Lines 136 Editorial Comment: Change mqsetattr() to mqgetattr(). _________________________________________________________________ OBJECTION 16 Section 9.4.2 Page 144 Lines 240-245 Problem: Behavior described here does not consider the effect of the MQWRAP flag. Action: Define behavior which does take into account the MQWRAP flag. _________________________________________________________________ COMMENT 4 Section 9.4.2 Page 144 Lines 240-245 Editorial Comment: This section is worded awkwardly and should be rewritten to make it clearer. _________________________________________________________________ OBJECTION 17 Section 9.4.3 Page 145 Lines 268-270 Problem: If our earlier objections on MSG_USE are accepted and MSG_USE is deleted, there is no problem here. Otherwise, there should be an option to allow a closing process to NOT have to wait for messages marked as MSG_USE to be delivered before the close system call can complete. It is not reasonable to force a real-time process to wait for something when it doesn't need to. Action: If MSG_USE remains, provide an option to allow a process to NOT have to wait for messages marked as MSG_USE to be delivered before the process goes away. _________________________________________________________________ OBJECTION 18 Section 9.4.5 Page 147 Lines 324-326 Problem: These lines refer to the ability to send a (void *)'s worth of data, which we have objected to earlier. Action: Replace the sentence on lines 324-326 to say that the msg_data field points to the message data. _________________________________________________________________ OBJECTION 19 Section 9.4.5 Page 147 Lines 332-359 Problem: With the removal of MSG_USE, MSG_COPY, and MSG_MOVE, none of this text is necessary. Action: Behavior when sending messages should be controlled strictly by the NONBLOCK flag set by fcntl. This means one of three things happens when a message is sent: 1. the message is successfully queued (either due to MQWRAP or space being available). 2. the process is blocked waiting for space in the queue, to be followed by successful queuing. (due to MQWRAP not being set, no space being available and O_NONBLOCK not being specified). 3. the message is rejected. (due to MQWRAP not being set, no space being available and O_NONBLOCK was specified). _________________________________________________________________ OBJECTION 20 Section 9.4.6 Page 149-151 Lines 400-472 Problem: In our objections on Chapter 7 (Asynchronous Event Notification) we believe the mechanism proposed by that chapter should be deleted from the standard. However, if the mechanism remains, there are several cases which can occur which are not defined by the existing draft. In particular: 1. What happens when multiple processes have requested asynchronous notification when a message arrives? Specifically, if more than one process has registered interest in one message, who gets it? First one to register, highest priority, or is the order undefined? 2. What happens when there is a mixture of processes synchronously waiting for a message and processes having requested asynchronous notification of a message arrival, when a message arrives. Specifically, if more than one process has expressed interest in one message, who gets it? Do synchronously waiting processes have priority over asynchronously notified processes? Is the first process that registers interest (either by waiting or by requesting asynchronous notification) the one that gets it, does the highest priority process the one, or is the order undefined? 3. Can a process request asynchronous notification and then later cancel that request? There doesn't appear to be a mechanism to do this, although clearly the kernel needs such a mechanism for processes that terminate. Action: Define the behavior (or explicitly indicate it is undefined) when these situations occur. Explicitly stating that such behavior is undefined would seem to violate the initial requirement for a deterministic data passing method. It is also acceptable (and desirable) to remove altogether the ability to receive messages asynchronously. _________________________________________________________________ OBJECTION 21 Section 9.4.11 Page 157-158 Lines 656-680 Problem: This operation is inherently unreliable, since the messages which are enqueued may be received by the receiving process (creating a race condition). Action: Since there doesn't seem to be any rationale for its inclusion, either provide rationale for this facility and fix the race conditions or (more preferably) delete this facility from the standard. _________________________________________________________________ OBJECTION 22 Section 9.4.12 Page 158 Lines 681-702 Problem: The mqgetpid facility does not appear to provide any useful function. Action: The rationale on lines 1063-1079 does not appear to justify the inclusion of such a facility, and, in fact, the rationale appears to justify its exclusion. We agree with the rationale. _________________________________________________________________ OBJECTION 23 Section 9.4.13,9.4.14 Pages 158-160 Lines 703-759 Problem: We have previously objected to sending a pointer's worth of data when there's no possible way to de-reference the pointer on the receiving end in any meaningful way. The facilities mqputevt() and mqgetevt() are just another mechanism for sending a short message but with a separate logical channel in the queue. We don't believe another mechanism is necessary. Action: Delete the putevt/getevt facility. _________________________________________________________________ OBJECTION 24 Chapter 9 Pages 137-176 Lines 1-1343 Problem: The interfaces in this chapter are not based on current practice. Lines 1175-1178 of the rationale seems to assume the only existing practice worthy of consideration to be BSD or System V. We believe there is significant existing practice, in addition to BSD and System V, that does not appear to have been considered by the working group. One particular example which comes to mind is MACH IPC. In addition, on Lines 1179-1196 the rationale for a new interface makes incorrect assumptions about both BSD and System V, and ignores the existence of several others which implement similar functionality. In particular, BSD does provide asynchronous notification of receipt of message, it does provide the sender of a message (for purposes of reply), and does allow using pathnames for identifying message queues (in the local case...the only case considered here). In addition, several other IPC interfaces are more general, in that they also provide support for networked environments, which is being considered by another IEEE working group. We believe the rationale for a new interface to be invalid, in that it is based on assumptions about existing interfaces which are incorrect. Action: The proposed interfaces should replaced with an existing interface, ideally one that has potential to be used in a distributed environment, including those in which the filesystems are not shared. _________________________________________________________________ OBJECTION 25 Chapter 9 Pages 137-176 Lines 1-1343 Overall Action: We believe there are several actions which will resolve our objections for this chapter. 1. Satisfy all of the above objections. 2. Substitute the entire chapter with one of several existing IPC mechanisms that provides the same functionality without the problems stated above. 3. Remove this chapter from this ballot and send this chapter back to the working group for further review. Without at least one of these actions, this ballot remains negative. _________________________________________________________________ CHAPTER 10. SYNCHRONOUS I/O --------------------------- OBJECTION 26 Chapter 10.3 Page 178,188 Line 39-40,369-370 Problem: The new O_FSYNC option has exactly the same behavior as the existing System V O_SYNC. This additional name is unnecessary. Action: The O_FSYNC option should be renamed O_SYNC to correspond to the behavior as currently defined by System V. _________________________________________________________________ OBJECTION 27 Chapter 10.4.5 Page 182-183 Line 148-176 Problem: rtfsync() allows the application to distinguish between O_SYNC and O_DSYNC. Because of the amount of optimization possible this distinction is at most one write per file transaction, it seems unnecessary to introduce a new interface for such a trivial optimization. Action: rtfsync() should be removed in favor of the fsync() system call we understand is being introduced by 1003.1b. Also the op parameter to afsync() should be removed for the same reason. _________________________________________________________________ OBJECTION 28 Chapter 10.4.6 Page 183-184 Line 177-228 Problem: The afsync() call takes a struct aiocb parameter which is part of the Asynchronous I/O mechanism. (Note. See objection relating to Asynchronous I/O chapter requiring the aiocb to be replaced by an I/O request handle, a signal number and an I/O completion record.) Action: The new interface should be handle = afsync(int filedes, int signal_number); This handle may be used with the completion status function defined in the Asynchronous I/O chapter ballot objection. The handle returned by this function should be passed to the signal handler in the sigcode parameter. _________________________________________________________________ CHAPTER 11 ASYNCHRONOUS I/O -------------------------- OBJECTION 29 Section 11.4.2.1 and 11.4.3.1 Page 194-196 Lines 111-112,168-169 Problem: Some parameters to the functions are on the parameter list and others in a control block? It appears there was some attempt to make the parameter list look like the existing read/write system calls. While this is somewhat noble, this obscures the interface. Action: Put all the relevant parameters into a control block, including the buffer address and the number of bytes to read/write, with the exception of the file descriptor. _________________________________________________________________ OBJECTION 30 Section 11.3.1 Page 192 Lines 28,51-54 Problem: Asynchronous event notification is used to deliver the I/O completion event. (Note. See objection relating to Asynchronous Event Notification chapter requiring event notification to be replaced with enhanced signals.) Action: The proposal for signals (as a replacement for the Asynchronous Event Notification) requires all references to struct event in the calls and data structures in this section to be changed to a signal number to be sent to the requesting process when the I/O is complete. The Asynchronous I/O handle should be passed to the signal handler in the sigcode parameter. _________________________________________________________________ OBJECTION 31 Section 11 Page 194-202 Problem: The address of the control block in the users address space is used as the ID in subsequent operations (returning status, canceling operations and determining the event id). This is both unprecedented in Unix and introduces the following problems; 1. Since the handle is allocated by the user rather than the system, handles could be reused before becoming inactive which prevents exit() from being able to clean up. 2. If the control block is an automatic variable and the requesting function returns, the behavior is undefined. This introduces the potential for frequent programming errors such as if the caller has no intention of looking at the control block again and returns while the system will still write into the aiocb later. Action: The aread()/awrite() calls should be modified to return a system generated handle which can be used in subsequent operations. listio() should be passed an array of handles to be filled in by the system for each request. acancel() should accept an array of handles to perform the operation on. _________________________________________________________________ OBJECTION 32 Section 11 Page 194-371 Problem: The I/O request information and the completion status have been combined into one control block. This causes potential problems on a multiprocessor where the device driver may have to invalidate the cache on another processor to get a polling user process on that other processor to read an updated completion code from the in-memory version of the asynch I/O control block. This operation is frequently very expensive. Action: Separate the data into a request block and a completion block. The completion block must contain at least the error number, the number of bytes actually transferred and the request handle. In order to poll for the status, a new interface must be defined which accepts the handle and returns the errno and one to return the completion block once the I/O has completed. This may be the same interface, eg errno = get_async_completion_block(handle, &completion_block); This allows a library routine to perform the polling operation, going into the kernel when cache-invalidates are more expensive than polling operations, and staying at user-level when cache-invalidates are less expensive than polling operations. When the I/O is complete and the application is notified via a signal, then a pointer to the completion record should be passed in the sigcode parameter to the handler. _________________________________________________________________ OBJECTION 33 Section 11.4.5 Page 200-201 Line 307-335 Problem: There is no justified requirement or rationale for the acancel() interface and we can see no immediate use for it. Action: If the existence of such a function can be justified it should be documented. Otherwise the interface should be removed. _________________________________________________________________ OBJECTION 34 Section 11.4.6 Page 201-202 Line 338-371 Problem: The iosuspend() facility is unnecessary because the application can use sigsuspend() to wait for I/O completion events and then can decide whether the proper subset has been completed. This is more flexible because any arbitrary completion predicate can be used, something not supported by the current iosuspend() facility. Action: Delete iosuspend(). _________________________________________________________________ CHAPTER 12. REAL-TIME FILES. ---------------------------- OBJECTION 35 Chapter 12 Pages 209-236 Problem: We do not believe sufficient justification has been given for the facilities defined by this chapter. Lines 874-876 state "The actual requirements for real-time file usage differ from non-real-time usage primarily in the areas of performance, guaranteed access to resources, and guaranteed delivery of data to a non-volatile media (that is, not memory). The rationale on lines 854-856 and 857-865 suggest that the proposed standard does not address the "Performance" and "Guaranteed delivery" requirements. Indeed, we agree that these areas are beyond the scope of a standard. With respect to the requirement for guaranteed access to resources, it should be noted that many implementations merely pre-write the file, since this not only guarantees access to resources but in most implementations is faster as well. As a result, we do not believe there is any demand for a standard which supports files distinguished as to be used for real-time purposes, and do not believe this chapter provides one. The current placebuf interface is inadequate because it accepts no file parameter which allows for differing blocking factors for each device. Also it cannot provide meaningful alignment information if the alignment is in increments larger than bufsize and that alignment is an input parameter and there is no mechanism to portably determine what it should be. Action: All the facilities in this chapter should be deleted except for those where the implementation advises the application how to structure I/O requests for optimal performance. The only valid examples in the current proposal are block size and buffer alignment. Volume-Number: Volume 19, Number 124