DN>
  > On a blocking call to DosRead() the size of the pipe management buffer
  > should be irrelevant. The thread reading the pipe should block until
  > the requested number of bytes has been obtained or the pipe is
  > disconnected.
DN>

  That isn't the behaviour of DosRead.  Unless there is an EOF (or
  timeout) condition, *all* that you are guaranteed is that DosRead will
  return a non-zero number of bytes *up to* the maximum size of the buffer
  that you specify.

  There's *no* guarantee that DosRead will fill your buffer entirely.

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

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

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

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

  > JdeBP <
___
 X MegaMail 2.10 #0:
--- Maximus/2 3.01