stream interfaces - with ranges

[Artur Skawina]

On 05/18/12 13:34, Dmitry Olshansky wrote:
> On 18.05.2012 8:19, kenji hara wrote:
>> I think range interface is not useful for *efficient* IO. The expected
>> IO interface will be more *abstract* than range primitives.
>>
>> ---
>> If you use range I/F to read bytes from device, we will always do
>> blocking IO - even if the device is socket. It is not efficient.
>>
>> auto sock = new TcpSocketDevice();
>> if (sock.empty) { auto e = sock.front; }
>>    // In empty primitive, we *must* wait the socket gets one or more
>> bytes or really disconnected.
>>    // If not, what exactly returns sock.front?
>>    // Then using range interface for socket reading enforces blocking
>> IO. It is *really* inefficient.
>> ---
> 
> There is no problem with blocking _interface_. That is the facade. The actual work can happen in background thread (and in fact it often is).
> So while you work with first chunk the next one is downloaded behind the scenes.
> Just take a look at std.net.curl all these asyncByChunk ... and then there is vide.d that shows that having blocking interface for asynchronous i/o is alright.

I just took a look, and yes, that's yet another slightly different implementation
of the same thing with a somewhat different interface:

   https://github.com/rejectedsoftware/vibe.d/blob/399b7a9d6eba9b14ea8d2215498daf53bd8d27d8/source/vibe/stream/stream.d

I thought i was exaggerating when i said 'thirteen', but there are already
more of them mentioned in this thread than i could count on one hand...

This one has an implicit flush and also this: "Finalize has to be called on
certain types of streams.". Not to mention it's class based.

artur