Michael Van Canneyt wrote:
The above implementation should not be changed, it is Delphi compatible:
TStream.ReadBuffer works on the assumption that Read will always return
the amount of bytes requested if they are available.
So, if you want to make changes, there is no reason why TStream.Read
should not benefit from 'trying harder', it could try harder to actually
get the requested number of bytes from the underlying low-level
implementation. Some TStream descendents already work that way
(compression, hash, encoding), others don't.
This in turn means that affected TStream descendents such as TFileStream
or THandleStream should try harder to read the requested number of
bytes, taking into account the
specifics of the underlying file/socket/whatever protocol.
In effect, you want to change all the streams Read method
implementation, such that it returns less than requested Count *only*
when the stream actually ended...
What about socket streams that potentially download the data? Or
THandleStream streams that *may* read/write data from/to a pipe, like
stdin/stdout, and may have to wait for another process? Should their
TStream.Read really hang, waiting for Count data?
1. See Ewald objections. Like Ewald, I also think it is useful to have a
TStream.Read that only returns the amount of data that is immediately
available (and hangs only when no data is available yet).
2. This would be large work, IMHO... I propose to fix a single
TStream.ReadBufffer implementation (well, and TStream.WriteBuffer). You
propose to fix Read method in all stream descendants, inside and outside
FPC sources.
Michalis
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
