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