2012/5/19 Steven Schveighoffer <schvei...@yahoo.com>:
> On Fri, 18 May 2012 10:39:55 -0400, kenji hara <k.hara...@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
