[snip]
-----
Question: Should we allow read to return an empty slice even if atEnd
is false? If we do, we allow non-blocking streams with burst transfer.
However, naive client code on non-blocking streams will be inefficient
because it would essentially implement busy-waiting.
Why not return an integer so different situations could be
designated? It's how the system call read works so you can tell no
data was read but that's because it's a non-blocking stream.
I realize it's sexy to return the data again so it can be used
immediately, but in practice it's more useful to return an integer.
For example, if you want to fill a buffer, you need a loop anyways
(there's no guarantee that the first read will fill the buffer), and
at that point, you are just going to use the length member of the
return value to advance your loop.
I'd say, return -1 if a non-blocking stream returns no data, 0 on EOF,
positive on data read, and throw an exception on error.
Maybe it's only me but I would prefer non-blocking IO not mixed with
blocking in such a way. Imagine function that takes an
UnbufferedInputTransport, how should it indicate that it expects only a
non-blocking IO capable transport? Or the other way around. Checking
return codes hardly helps anything, and it means supporting both types
everywhere, which is a source of all kind of weird problems.
From my (somewhat limited) experience, code paths for blocking and
non-blocking IO are quite different, the latter are performed by
*special* asynchronous calls which are supported by all modern OSes for
things like files/sockets.
Then my position would be:
1) All read/write methods are *blocking*, returning empty slices on EOF.
2) Transport that supports asynchronous IO should implement extended
interfaces like
interface AsyncInputTransport: UnbufferedInputTransport{
void asyncRead(ubyte[] buffer, void delegate(ubyte[] data)
callback=null);
}
interface AsyncOutputTransport: UnbufferedOutputTransport{
void asyncWrite(ubyte[] buffer, void delegate(ubyte[] data)
callback=null);
}
Where callback (if not null) is called with a slice of buffer containing
actual read/written bytes on IO completion.
Any calls to read/asyncRead while there is asynchronous IO operation
going on should throw, of course.
Regarding buffering transports I agree with Steven, they shouldn't be
interfaces *derived* from Unbuffered...Transport.
Speaking of the above the ubyte[] front property of whatever buffered
range-like construct we settle on IMHO should be blocking, since you
can't get any advantage over this by making front return an empty
slices or throw exceptions on "would block" situations.
--
Dmitry Olshansky
