Another file handles question/comment
Barry Traylor
barry at PRC.Unisys.COM
Thu Aug 24 14:37:40 AEST 1989
From: barry at 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 at prc.unisys.com
Volume-Number: Volume 17, Number 9
More information about the Comp.std.unix
mailing list