StreamReader/ReadBlock

  • Thread starter Thread starter Rene
  • Start date Start date
R

Rene

The documentation has the following remark for the ReadBlock method of the
StreamReader: "The method blocks until either count characters are read, or
all characters have been read".

What kind of blocking are they referring to? Are they referring to the
BaseStream being blocked so that no other process can read or write to it?

For example, in the case of a StreamReader based on FileStream, does this
mean that the actual file on the hard drive will be blocked for read, write
etc? Or does it mean that the stream on memory is the one that is blocked?
Is the blocking occurring for only the bytes after the FileStream position?
Am I totally not getting it?



Thanks.
 
Rene said:
The documentation has the following remark for the ReadBlock method of the
StreamReader: "The method blocks until either count characters are read, or
all characters have been read".

What kind of blocking are they referring to? Are they referring to the
BaseStream being blocked so that no other process can read or write to it?
Click to expand...

No, they're referring to the method not returning. It doesn't change
whether or not anything else can read or write to the stream.

Basically, it means that you can rely on StreamReader.ReadBlock not
returning until either it's read as much as you've asked it to, or it's
reached the end of the stream.
For example, in the case of a StreamReader based on FileStream, does this
mean that the actual file on the hard drive will be blocked for read, write
etc? Or does it mean that the stream on memory is the one that is blocked?
Is the blocking occurring for only the bytes after the FileStream position?
Am I totally not getting it?
Click to expand...

I think you're totally missing it, I'm afraid :)
 
Hey John:

Believe or not, that was the first thing that occurred to me but when I
thought of that it didn't compile in my head!

I mean, most of the function calls to objects won't return until the work is
done (that's kind of expected behaviors in my opinion). Inside my little
head I thought that the Read() method would not return until everything was
read and that the ReadBlock was not doing what you just said because if that
was the case, it would have been named something like
ReadAsynchronous(delegate FunctionToCallWhenFinishReading).

Oh well, thanks for clearing every thing.
 
Rene said:
Believe or not, that was the first thing that occurred to me but when I
thought of that it didn't compile in my head!

I mean, most of the function calls to objects won't return until the work is
done (that's kind of expected behaviors in my opinion). Inside my little
head I thought that the Read() method would not return until everything was
read and that the ReadBlock was not doing what you just said because if that
was the case, it would have been named something like
ReadAsynchronous(delegate FunctionToCallWhenFinishReading).

Oh well, thanks for clearing every thing.
Click to expand...

In this case it's not a case of potentially being asynchronous - it's a
case of potentially returning when only some of what you requested has
been read, and stopping there. That's what Stream.Read does, for
example.
 
Back
Top