Re: [boost] Re: [network] An RFC - updated

From: Iain Hanson (Iain.Hanson_at_[hidden])
Date: 2005-04-22 10:29:51

On Fri, 2005-04-22 at 16:24 +0200, Peter Simons wrote:
> Iain Hanson writes:
> 
>  >>> This would give a significant performance hit as there
>  >>> will now be two copies of the data.
> 
>  >> Not if the callback doesn't make any copies.
> 
>  > That is a long way from being the common case.
> 
> Maybe, maybe not. My point is that whether or not data has
> to be copied depends on the _callback_, not on the I/O
> driver. Your original statement made it appear as if copying
> of data would be inevitable in a callback-driven design --
> and it is not.
> 
No. Copying the data becomes probable when the lib provides the buffer.
Nothing to do with callbacks.

> 
>  > I really don't see this as workable in the general case.
>  > The library has to guess the size of the read buffer.
> 
> No, the caller can provide the capacity (or the buffer).
> 
> 
>  > It would also prevent reading a complete record on a
>  > stream by reading a header up to the length field and
>  > then making a 2nd read call for that length with the
>  > correct size buffer.
> 
> Why exactly would that be impossible in a callback-driven
> design?
> 
> 
>  > It would also add dynamic memory allocation to the
>  > library [...].
> 
> Let the user pass the buffer when calling the driver, and
> then there's no memory management at all.

This is what I was arguing for.

/ikh