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