Path: utzoo!utgpu!attcan!uunet!husc6!linus!alliant!jeff
From: jeff@Alliant.COM (Jeff Collins)
Newsgroups: comp.sys.encore
Subject: Re: File buffers
Keywords: Buffered file input
Message-ID: <2185@alliant.Alliant.COM>
Date: 3 Aug 88 11:55:04 GMT
References: <585@cmx.npac.syr.edu>
Reply-To: jeff@alliant.UUCP (Jeff Collins)
Distribution: na
Organization: Alliant Computer Systems, Littleton, MA
Lines: 26

In article <585@cmx.npac.syr.edu> anand@cmx.npac.syr.edu (Rangachari Anand) writes:
>
>  This is a problem that others have surely faced on multiprocessors
>  such as the Multimax. Consider a program which forks a number of 
>  child processes each of which need to do I/O from a given file. If the 
>  fscanf and fprintf functions are used, the buffering action seems to
>  load a block of the file into a buffer which is in the private memory 
>  of a process. Then when other processes attempt to read from the
>  same file, they load blocks of the file into their respective buffers.
>  Thus they cant read the file in the correct sequence.

	Yes this is definately a problem.  Given the buffering syntax
of stdio, there is really no way to do what you want.  The only
suggestions that I would have would be to use read(2)/write(2)
directly (ie. eliminate the buffering).  This is fairly painfull as
you don't get the functionality of fscanf and fprintf.  Perhaps you
can do an sprintf(3) into a string, then write(2) the string to the
file.  Reading may be more difficult because you probably don't know
the length to read until after you have read it.

	The other possible alternative is to change the stdio
libraries so that the buffers use shared memory.  I wouldn't think
that this would be a trivial solution, and is probably not something
that you would want to do yourself - but it is an idea.

	Jeff Collins