stream interfaces - with ranges

Steven Schveighoffer schveiguy at yahoo.com
Fri May 18 06:52:52 PDT 2012


On Fri, 18 May 2012 07:05:50 -0400, Artur Skawina <art.08.09 at gmail.com>  
wrote:

> On 05/18/12 06: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.
>
> No. 'empty' has to return true only _after_ seeing EOF.
>
> Something like 'available' can return the number of elements known
> to be fetchable w/o blocking. [1]
>
>>   // If not, what exactly returns sock.front?
>
> EWOULDBLOCK :^)
>
> But, yes, it needs to block, as there's no generic way to return
> EAGAIN/EWOULDBLOCK. This is where the primitive returning a slice
> comes in - that one /can/ return an empty slice.
> So '!r.empty && r.fronts.length==0)' is the equivalent to EAGAIN.
> (and note i'm oversimplifying -- 'fronts' can return something that
> /acts/ as a slice; which is what i'm in fact are doing)

I think this is an example of what Kenji and I are talking about -- trying  
to make the range interface map to *all* I/O situations.

> I don't see any reason to invent yet another abstraction, when ranges
> can be made to work with some improvements.
>
> Ranges are just a convention; not a perfect one, but having /one/, not
> two or thirteen, is valuable. If you think ranges are flawed the
> discussion should be about ripping out every trace of them from the
> language and libraries and replacing them with something better. If
> you think that would be bad - well, having tens of different incompatible
> abstractions isn't good either. (and, yes, you can provide glue so that
> they can interact, but that does not scale well)

My opinion is that ranges should be available for i/o when you need to  
hook them to some other range processing code, but they shouldn't be the  
preferred interface for all I/O.

-Steve


More information about the Digitalmars-d mailing list