stream interfaces - with ranges

kenji hara k.hara.pg at gmail.com
Fri May 18 10:43:52 PDT 2012


2012/5/19 Steven Schveighoffer <schveiguy at yahoo.com>:
> On Fri, 18 May 2012 10:39:55 -0400, kenji hara <k.hara.pg at gmail.com> wrote:
[snip]
>
> On non-blocking i/o, why not just not support range interface at all?  I
> don't have any problem with that.  In other words, if your input source is
> non-blocking, and you try to use range primitives, it simply won't work.
>
> I admit, all of my code so far is focused on blocking i/o.  I have some
> experience with non-blocking i/o, but it was to make a blocking interface
> that supported waiting for data with a timeout.  Making a cross-platform
> (i.e. both windows and Posix) non-blocking interface is difficult because
> you use very different mechanisms on both OSes.
>
> And a lot of times, you don't want non-blocking i/o, but rather parallel
> i/o.

[snip]
>> No, we cannot map output range concept to non-blocking output. 'put'
>> operation always requires blocking.
>
> Yes, but again, put can use whatever stream primitives we have.
>
> In other words, it's quite possible to write range primitives which utilize
> stream primitivies.  It's impossible to write good stream primitives which
> utilize range primitives.

[snip]
>> My policy is very similar. But, as described above, I think range
>> cannot cover non-blocing IO.
>> And I think non-blocking IO interface is important for library
>> implementations.
>
>
> I think you misunderstand, I'm not trying to make ranges be the base of i/o,
> I'm trying to expose a range interface *based on* stream i/o interface.

The reasons why not use range primitives directly for stream I/O.

1. To specify a buffer for storing read bytes from upper layer.

Input range doesn't have a way to specify buffer for storing read
bytes to lower layer.
Because input range is designed as a view of underlying container.

Comparison of primitive count.
The four or more primitives: empty + front + popFront +
specifiy-buffer-for-storing-read-bytes + ...
vs.
My 'pull' primitive

Which is better?

2. To avoid confusing I/O operation/interfaces and range ones.

Yes, if you only needs blocking-io, you can use range i/f instead of
i/o specific primitives, but it is very confusable.
I think that enforcing to wrap IO objects (like File) with thin range
wrapper is better for orthogonality.

  foreach (ubyte b; RawFile(fname).ranged) { ... }

Kenji Hara


More information about the Digitalmars-d mailing list