www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - appendToFront semantics

reply Torarin <torarind gmail.com> writes:
I've been experimenting with Andrei's buffered input range and noticed
that appendToFront(size_t n) may benefit from a slightly different
definition.

Andrei describes it as appending at most n elements to the front. But
if you change that to "at least", the range can ask the underlying
stream to also fill any unused space in the buffer.

If unused space is available before doing the append, this can also be
achieved by doing appendToFront(0) until you reach the desired
front.length. But if that leads to a move of buffered data, it becomes
less efficient than it could be.

The change means you would lose the ability to limit the amount read
from the underlying stream, which could be useful for a e.g. a
protocol switch, but I'm inclined to think that's less important than
the efficiency of the common case.

Did I miss the reason why this doesn't work well?

Torarin
Feb 15 2011
parent reply Adam Ruppe <destructionator gmail.com> writes:
One problem with "at least" is it might have to wait for two
packets to come off the network interface; could be fairly slow.

The "at most" means it will take whatever is available without
overflowing your buffer - it will never wait if there is any
data available.
Feb 15 2011
next sibling parent reply Torarin <torarind gmail.com> writes:
2011/2/15 Adam Ruppe <destructionator gmail.com>:

 One problem with "at least" is it might have to wait for two
 packets to come off the network interface; could be fairly slow.

 The "at most" means it will take whatever is available without
 overflowing your buffer - it will never wait if there is any
 data available.


But isn't the reason you're supplying a value to appendToFront that
you do want a specific amount? If not, you can use appendToFront(0)
until you get what you want.

Torarin
Feb 15 2011
parent Adam Ruppe <destructionator gmail.com> writes:
Torarin:

 But isn't the reason you're supplying a value to appendToFront that
 you do want a specific amount?


I figured it was just to give precision control over memory usage...
Feb 15 2011
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/15/11 12:10 PM, Adam Ruppe wrote:

 One problem with "at least" is it might have to wait for two
 packets to come off the network interface; could be fairly slow.


Another is that the stream may end... so there's no guarantee.

Andrei
Feb 15 2011
parent reply Torarin <torarind gmail.com> writes:
2011/2/15 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:

 On 2/15/11 12:10 PM, Adam Ruppe wrote:

 One problem with "at least" is it might have to wait for two
 packets to come off the network interface; could be fairly slow.


 Another is that the stream may end... so there's no guarantee.

 Andrei


If the stream ends it would return short. Anyway, my main point was to
allow it to read more than n elements. So if you give it the
definition "try to append n elements or more" it caters for the "don't
block and don't consume more memory than this" situation as well.

Torarin
Feb 15 2011
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/15/11 5:21 PM, Torarin wrote:

 2011/2/15 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org>:

 On 2/15/11 12:10 PM, Adam Ruppe wrote:

 One problem with "at least" is it might have to wait for two
 packets to come off the network interface; could be fairly slow.


 Another is that the stream may end... so there's no guarantee.

 Andrei


 If the stream ends it would return short. Anyway, my main point was to
 allow it to read more than n elements. So if you give it the
 definition "try to append n elements or more" it caters for the "don't
 block and don't consume more memory than this" situation as well.

 Torarin


I think that would work!

Andrei
Feb 15 2011