Mail Archives: djgpp-workers/2001/08/26/06:14:39
> > If you are interested in implmentation of pipe techical
> > details, I'll tell you some other interesting things NT/2K do :-)
>
> Yes, please.
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. 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.
Some operations complete (like seeks and reads) can complete when the
pipe is not complete (when the upstream is still running). Others like
seek to end of pipe stall until the upstream is complete and close the
handle.
So it's a hybrid that takes the best of Unix pipes and DOS seekability.
No wonder it's a bit flakey :-)
> > core routine (say _seek?) instead of patching 5 files
> > (llseek, filelen, is_exec, lfilelen, lseek).
>
> I don't see any problem to make them all call a single function. But
> let's first find the best solution for that single function.
If the filelen patch is OK we don't have to do anything, but we ought to
consider it anyway ...
> > But if the seek to end behavior provides bug immunity, a much simpler fix.
>
> Doesn't seek to current also solve the problem? If it does, it should be
> much cheaper (seek to end could be slow on large files).
But seek to end is a one time fix (never have to do it again) while the
seek to current must be done before each seek (or so we currently believe,
maybe it only has to be done once ?)
The seek to end is also needed for fstat() to get the size anyway.
- Raw text -