On Sunday, 96/11/17, Jonathan de Boyne Pollard wrote to David Noon
about "blockreading from a pipe" as follows:

JP> DN>
JP>   > On a blocking call to DosRead() the size of the pipe management buffer
JP>   > should be irrelevant. The thread reading the pipe should block until
JP>   > the requested number of bytes has been obtained or the pipe is
JP>   > disconnected.
JP> DN>
JP> 
JP>   That isn't the behaviour of DosRead.  Unless there is an EOF (or

Hi Jonathan,

I didn't say that it was the behaviour of DosRead(). I said it should
be the behaviour.

JP>   I tested this with a simple program (source follows in next message),
JP>   and it turns out that DosRead will empty all existing data in a pipe's
JP>   buffers and return.  It will *not* wait for more data to be written.

I don't doubt that. But, IMO, it should block until a logical end
point has occurred:
   Application buffer is full;
   Pipe is disconnected;
   Timeout has occurred.

That is what I meant in the final sentence of the paragraph you
quoted, above.

JP>   After all, how can it know that there exist more data to *be* written ?

If the pipe hasn't been disconnected there is more to come. There is
at least a disconnect status to be detected.

JP>   I disagree strongly with your contention that returning a partially
JP>   filled buffer is, somehow, broken.  DosRead returns partially filled
JP>   buffers in all sorts of situations.  The CON device returns partially
JP>   filled buffers (imagine being forced to pad every command that you type
JP>   with spaces so that it was 256 characters long); serial devices return
JP>   partially filled buffers when the read times out; files return partially
JP>   filled buffers when you reach the end of the file.

But these are logical ends of records, appropriate to the devices
involved. One should expect them to return short buffers, just as one
should expect a pipe to return a short buffer _if_ it is disconnected.

JP>   Pipes are nothing special in this regard.  And partially filled buffers
JP>   are something that you should expect.

... but only under certain conditions.

[But we deal with them anyway.]

Regards

Dave


 * KWQ/2 1.2i * Windows NT: From the makers of Windows 3.1!
--- Maximus/2 3.01