barry@PRC.Unisys.COM (Barry Traylor) (08/24/89)
From: barry@PRC.Unisys.COM (Barry Traylor) Unfortunately, being a recent subscriber to usenet, I missed all but Donn Terry's followup on the discussion of File Handles. Could the submitters (who happen to consider their submissions on the subject interesting) forward their articles to me. Within my development group there has been some debate about the file handle issue. I believed the onus was on the implementation, but was convinced by associates, more imbued with the Unix tradition than myself, that that was not the case, that the onus was on the application. Donn's followup leads me to believe that my first assumption was correct. This unfotunately leads me to a degree of confusion and consternation. My understanding, from reading the (extensive) verbiage in 1003.1, chapter 8, is that the intent of the rules is to preserve a given "stream"'s view of the file (behind a file description) given that there may be (possibly) conflicting usage of the file description by both other file descriptor I/O and other "stream" I/O (of course eventually using file desriptors). Am I correct in this? If I am correct, then I believe a race condition can occur between uncoordinated streams using a file description with regard to underlying lseek and read (or write) calls. Given that stream I/O is almost always implemented as a library, and that synchronization mechanisms (other than fcntl locking, which I believe cannot be applied in this case, at least using the open file description in question) and shared memory mechanisms (for cross task usage) are not provided, it is not clear to me how the race condition can be avoided by the interfaces provide in 1003.1. I do realize, however, that such synchronization methods will be provided in 1003.4, but that the use of such might be (somewhat) painful in a library environment. While the race can occur on a uniprocessor system that allows for the interruption and rescheduling of processors to processes, this problem can become quite noticeable with multiprocessor systems. Am I missing something here? It seems clear to me that there is no way of avoiding the case where stream A (in process PA) does a lseek()/read() and stream B (in process PB) does an lseek()/read() to a different part of the file, that lseek() A -> lseek() B -> read() A -> read() B, can be reliably prevented, short of using fairly painful library-coordinated locking mechanism between the lseek()s and read()s. I am now seriously considering implementing kernel rread() (random read) and rwrite() (random write) functions so as to avoid the race. Barry Traylor Unisys Corp, A Series Engineering Paoli, Pa. e-mail: barry@prc.unisys.com Volume-Number: Volume 17, Number 9
donn@hpfcdc.HP.COM (Donn Terry) (08/28/89)
From: donn@hpfcdc.HP.COM (Donn Terry) To answer Barry Traylor's questions simply: The onus is on BOTH the implementation and the application. First, remember that in this case "application" and "process" are disctinct things. In particular, an application can consist of several processes, not all of which were written by the application writer (e.g., system utilities such as grep). The *application* is constrained so that to conform to POSIX only one file handle for a file is in use at a time, across ALL processes in the application, and that hand-off of file handles be done as required. The *implementation* is constrained so that if the application follows this rule, it will in fact work. (Note that pre-POSIX implementations didn't do enough so that the application had a chance at all of making it work.) I think that some of the confusion comes from trying to make it exclusively one or the other's total responsibility. In the rationale it says that the rules are stated so that the application has "a fighting chance" of doing this, not that it will work in every possible combination. If this doesn't help then let's (on the net) look at it in more detail. Donn Terry (not speaking in any 'official' way) Volume-Number: Volume 17, Number 11
gwyn@brl.arpa (Doug Gwyn) (08/28/89)
From: gwyn@brl.arpa (Doug Gwyn) In article <378@longway.TIC.COM> barry@PRC.Unisys.COM (Barry Traylor) writes: >Within my development group there has been some debate about the file handle >issue. I believed the onus was on the implementation, but was convinced by >associates, more imbued with the Unix tradition than myself, that that >was not the case, that the onus was on the application. Your associates are correct (as I interpret IEE Std 1003.1-1988). The stuff about file handles is intended to allow the implementation to NOT have to synchronize file descriptors with stdio streams and vice-versa. It is up to the application to take steps to assure such synchronization when switching back and forth between multiple handles on the same underlying open file description. The intention is NOT to force extensive use of semaphores in the library, quite the opposite. Volume-Number: Volume 17, Number 10
donn%hp-sdd@hpfcdc.HP.COM (Donn Terry) (08/29/89)
From: donn%hp-sdd@hpfcdc.HP.COM (Donn Terry) Just a vote to back up Doug's interpretation as well. It agrees with mine if there is any question in anyone's mind. Donn Terry (Speaking only for myself) Volume-Number: Volume 17, Number 12