On Fri, 2005-04-22 at 13:07 +0200, Peter Simons wrote:
Iain Hanson writes:
async_read should not take a buffer; instead, the callback should receive a pointer to a buffer managed by the library that is guaranteed to be valid for the duration of the callback. (Not by default, at least.)
async_write (by default) should not assume that the passed buffer stays valid after async_write returns.
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. /ikh
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.
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. Peter
participants (2)
-
Iain Hanson -
Peter Simons