Date:	Sun, 26 Aug 2001 16:25:46 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Charles Sandmann <sandmann AT clio DOT rice DOT edu>
cc:	acottrel AT ihug DOT com DOT au, djgpp-workers AT delorie DOT com
Subject:	Re: Read 3F00 STDIN problem on Win 2K ( was Re: Fseek on STDIN problem on Win 2K)
In-Reply-To:	<10108260745.AA16764@clio.rice.edu>
Message-ID:	<Pine.SUN.3.91.1010826161926.7088D-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Sun, 26 Aug 2001, Charles Sandmann wrote:

> If the amount of data is small, it stays completely in memory.  If the
> amount of data becomes large, it creates a file in the %TEMP% directory
> to buffer the data.

Actually, it's possible that it always goes to the temporary file, but 
due to disk caching, if the file is small, it gets consumed before the 
cache is flushed.  Assuming that the OS allows one application to read a 
file while another writes to its end (I already know that NT supports 
that, since "tail -f" works as expected on NT), you can have a credible 
pipe simulation with a disk file.

> So, my dir \ /s on my disk takes over 4Mb.  I 
> piped that to a djgpp app which would read, seek, read, seek, etc.
> Eventually I could read/seek anywhere in the pipe - by that time it
> buffered the entire thing to disk.

The fact that the pipe is seekable is actually an evidence that it's disk 
based.  The strange behavior wrt seeking is probably due to the jugglying 
the OS needs to support simultaneous reads/writes to the same file.  I 
guess their caching of the file pointer is flakey.

- Raw text -