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

  It isn't the behaviour of any read API call on just about any
  widely-used operating system on the planet.  Why should you want OS/2 to
  be so different ?  The POSIX 1003.1 read() call can return incomplete
  buffers.  Why should OS/2's DosRead() not do so ?

DN>
  > 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.
DN>

  Emptying the pipe's internal buffer *is* a logical endpoint.  As I said
  in the last message, there is no way for the thread calling DosRead to
  determine that there will _be_ any more data to be written.

  And what happens if you *do* change the semantics of DosRead so that it
  waits indefinitely until the user buffer is filled or the write end of
  the pipe is closed ?

  Under the current semantics, the read end of a pipe isn't delayed in
  returning what data were available if the write end of the pipe is not
  closed promptly.

  This is a common situation when people do things like redirect the
  standard output of a program to a pipe, and the program takes a long
  time to execute, but doesn't actually send anything to its standard
  output except maybe a copyright message at program startup.

  With the current semantics, that copyright message is received and
  processed immediately by the read end of the pipe (which may be
  something like the TEE command, displaying the output in "real time" for
  the user as well as logging it to file for later perusal)

  With the the semantics that you think it *ought* to have, however (where
  a partially filled DosRead is blocked until the write end of the pipe is
  closed), the copyright message in the above example won't be seen by the
  TEE command until the first program has run to completion and exited
  (unless it fills the TEE command's read buffer).  This isn't very
  satisfactory, especially if the program takes a long time to run.  Data
  shouldn't "stall" in a pipe like that.

  For another example :  If you redirected the output of your C++ compiler
  through a pipe to the TEE command, and the compiler produced one error
  message early on, and spent a further five minutes processing the rest
  of the file, would you want to see that error message as soon as
  it was generated, or would you want to wait the five minutes until the
  compiler had finished before you saw it ?

DN>
  > JdeBP> I disagree strongly with your contention that returning a partially
  > JdeBP> filled buffer is, somehow, broken.  DosRead returns partially filled
  > JdeBP> buffers in all sorts of situations.  The CON device returns partiall
  > JdeBP> filled buffers [...]; serial devices return partially filled
  > JdeBP> buffers when the read times out; files return partially filled
  > JdeBP> buffers when you reach the end of the file.
  >
  > But these are logical ends of records, appropriate to the devices
  > involved.
DN>

  Not true.  A serial device timeout is not a "logical end of record".
  It's just a gap.  It *could* be caused by the remote device coming to
  the end of a "packet" of data.  But it *also* could be caused by a delay
  in datacomms equipment (such as a multispeed modem deciding to
  renegotiate, or retransmission due to error-correction).

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