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.
-- Dmitry Olshansky
