Re: [boost] Re: [network] An RFC - updated

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.

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