On Saturday, 96/11/30, Udo van den Heuvel wrote to David Noon about
"blockreading from a pipe" as follows:

UH> I also found out that although my buffer is 8K (OS/2 
UH> doesn't give me more bytes per read so a bigger buffer is 
UH> of little use) my program sometimes reads less bytes, even 
UH> though It's reading in the middle of a file (I tried piping 
UH> the nodelist through it as a test).
UH> Is this because of the asynchronousness (sp?) of the pipe?

Hi Udo,

If anything it is the opposite. Your program is being synchronised
with the buffer management of the pipe support routines, rather than
being allowed to run at its own pace, which must be no faster than that
of the writing thread.

Under present arrangements, the timing of the pipe buffer management
routines affects the timing of both the read and write threads. My
contention is that it shouldn't. Its role should be solely as a broker
or arbitrator, allowing the write thread to pace the read thread.

However, there is a reason, of pure expedience, for IBM coding the
pipe support this way. It gets rid of data from the buffers quickly and
makes room for the writing thread to add more.

UH> Would it be possible to read 0 bytes although the program 
UH> isn't at the end of the file being piped, yet?

It shouldn't be possible. If no bytes are available in the buffer your
read thread should block.

UH> Can I increase this 8K limit somehow?

No. If it isn't filling 8K it won't fill anything bigger.

UH> Blockread (pascal) is the fastest way of getting data (text) from
UH> stdin?

I would expect so. I presume it is a very thin wrapper on the
DosRead() API.

Regards

Dave


 * KWQ/2 1.2i * WARP, SEX, BOOZE !!  What else does anyone need?

--- Maximus/2 3.01