From: Iain Hanson (Iain.Hanson_at_[hidden])
Date: 2005-04-22 13:04:50
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.
> > 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
> > 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
And use the active object pattern instead of callbacks
( producer/consumer ) :-).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk