Path: utzoo!attcan!uunet!longway!std-unix
From: barry@PRC.Unisys.COM (Barry Traylor)
Newsgroups: comp.std.unix
Subject: Another file handles question/comment
Message-ID: <378@longway.TIC.COM>
Date: 24 Aug 89 04:37:40 GMT
Sender: std-unix@longway.TIC.COM
Reply-To: barry@PRC.Unisys.COM (Barry Traylor)
Lines: 50
Approved: jsq@longway.tic.com (Moderator, John S. Quarterman)

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