digitalmars.D - appendToFront semantics
- Torarin (16/16) Feb 15 2011 I've been experimenting with Andrei's buffered input range and noticed
- Adam Ruppe (5/5) Feb 15 2011 One problem with "at least" is it might have to wait for two
- Torarin (5/10) Feb 15 2011 But isn't the reason you're supplying a value to appendToFront that
- Adam Ruppe (2/4) Feb 15 2011 I figured it was just to give precision control over memory usage...
- Andrei Alexandrescu (3/5) Feb 15 2011 Another is that the stream may end... so there's no guarantee.
- Torarin (6/12) Feb 15 2011 If the stream ends it would return short. Anyway, my main point was to
- Andrei Alexandrescu (3/18) Feb 15 2011 I think that would work!
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
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
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
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
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
2011/2/15 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:On 2/15/11 12:10 PM, Adam Ruppe wrote: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. TorarinOne 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
On 2/15/11 5:21 PM, Torarin wrote:2011/2/15 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org>:I think that would work! AndreiOn 2/15/11 12:10 PM, Adam Ruppe wrote: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. TorarinOne 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