On Fri, 2005-04-22 at 20:03 +0300, Peter Dimov wrote:

Iain Hanson wrote:

...

I really don't see this as workable in the general case. The library has to guess the size of the read 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.

This is a good point, but async_read can take a size parameter, even when the client does not supply a buffer.

True.

...

It would also add dynamic memory allocation to the library

I'm not sure that you can beat the library from the client side with respect to the number of memory allocations. With N asynchronous reads active you need to keep N buffers alive. The library can manage with just one in the select case.

pre-allocate a set of buffers and hold them in condition variable protected queue.

...

and be a source of runtime errors as a result a user not copying the buffer and trying to use it after its lifetime expired.

I'm fairly confident that manual buffer management will introduce even more runtime errors. ;-) (That's been my experience with async reads/writes, at least.)

And use the active object pattern instead of callbacks ( producer/consumer ) :-). /ikh