[RFC] I/O and Buffer Range

Dmitry Olshansky dmitry.olsh at gmail.com
Fri Jan 17 07:40:02 PST 2014


17-Jan-2014 18:52, Steven Schveighoffer пишет:
> On Fri, 17 Jan 2014 09:12:56 -0500, Dmitry Olshansky
> <dmitry.olsh at gmail.com> wrote:
>
>> 17-Jan-2014 18:03, Steven Schveighoffer пишет:
>>> On Fri, 17 Jan 2014 05:01:35 -0500, Dmitry Olshansky
>>> <dmitry.olsh at gmail.com> wrote:
>>>
>>>> BTW I haven't thought of writing into the buffer, but it works exactly
>>>> the same. It could be even read/write -"discarded" data is written to
>>>> underlying stream, freshly loaded is read from stream. Now in case of
>>>> input stream only writes are nop, for output-only reads are nops.
>>>>
>>>> With pinning it makes for cool multi-pass algorithms that actually
>>>> output stuff into the file.
>>>
>>> In my experience, the code/process for a write buffer is significantly
>>> different than the code for a read buffer. A read/write buffer is very
>>> difficult to make, because you either need 2 file pointers, or need to
>>> constantly seek the single file pointer to overwrite the existing data.
>>>
>>
>> Agreed, read/write buffer is a bad idea. As for write-only buffer
>> implemented in the same style as read-only, well I need to try it first.
>>
>
> Keep in mind that a read/write buffered stream *should* exist. It's just
> that you need to switch how you use the buffer.

I'm doubting that actually. Just use the freaking MM-file directly you'd 
better off efficiency wise. And there would be no need to switch back 
and forth. Modern OS use paging subsystem for files anyway (unless 
opened with O_DIRECT or similar).

> I think in my code, what I do is if someone wants to read, and is
> currently writing (on a read/write stream), I flush the buffer, then
> switch it to be in read mode, and then seek to the appropriate place, to
> fill the buffer.
>
> When switching from read to write, it's much easier, since the buffer
> starts out empty.
>
> So I think a buffer type that can be used for read *OR* write is good,
> just not simultaneously.

See above. I don't think there is a need for these paces with flushing 
stuff. And if it comes to pipes and sockets then just having 2 buffers 
fits the bill better.

> However, simultaneous read/write is probably something that could be
> useful for a niche use case (e.g. some transformative process), as long
> as you don't mind having 2 file descriptors open :)
>


-- 
Dmitry Olshansky


More information about the Digitalmars-d mailing list