On Fri, 15 Oct 2010 23:54:32 +0400, Kagamin <[email protected]> wrote:
Denis Koroskin Wrote:
> I think, it's better to inherit Stream from InputStream and
OutputStream.
> Do you even need endOfStream? From my experience, it's ok to
> blocked-read and determine end when 0 is read. Even if you read from
> network, is there a point in non-blocking read?
>
Probably, I think I'll try both ways and see which one turns out to be
better.
I should say, that implementation will be somewhat tricky, as different
kinds of streams handle reads beyond end in different ways. Say, reading
from a pipe whose write end is closed results in an error.
Either way is fine with me. But I agree yours is handy, too.
I was actually thinking about a plain ubyte[] read(); method:
struct BufferedStream
{
ubyte[] read(); // just give me something
}
Funny idea.
Here we can also think about MemoryStream: when you have all the data in
memory, you don't need user side buffer, and can just return direct
slice to data as const(ubyte)[].
Yeah. I'm also investigating into reading/sending multiple buffers at once
(aka scatter-gather I/O:
http://www.delorie.com/gnu/docs/glibc/libc_246.html)
It most likely won't be a part of a Stream interface, because I'd like to
support different types of buffer ranges, and that asks for a templated
implementation:
size_t writeRange(Range)(Range buffers);
Each element of Range needs to be of type ubyte[], and no other
requirements. Returns number of bytes written (not number of buffers,
because data transmission might stop at a middle of buffer.
