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

From: Michel André (michel.andre_at_[hidden])
Date: 2005-04-22 18:17:26

Peter Dimov wrote:
> Michel André wrote:
> 
>> Peter Dimov wrote:
>>
>>> Iain Hanson wrote:>
>>> 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.
>>
>>
>> Should several pending reads be allowed? I have leaned back and forth
>> on this issue in a previous platform specific async com library I wrote.
> 
> 
> Definitely; a server that has N active connections might have up to N 
> reads active at any time. Not on the same socket, of course. :-)

Of course, I was refering to the same socket/stream object not overall 
;). My implentation supported several pending receives on the same 
socket but none of the clients that i know of or wrote ever used it. And 
it would require further synch at the session level if ordering between 
messages are needed since partial messages could arrive out of order if 
one thread gets descheduled between dequeuing recv1 and dispatching 
recv1 to callback and the next thread completed and dispatched recv2.

>>> 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.)
>>
>>
>> Do you have any preferences as wheter to use basic_streambuf or not as
>> the buffer interface?
> 
> 
> I'm not sure what basic_streambuf would buy me over char[] or vector<char>.

The same goes for me, but Jeff Garland proposed looking into 
basic_streambuf. It would give possibility to supply your own 
implementation and maybe an easier way to intergrate with io streams. I 
think vector<char> would be good enough to use as send and receivebuffer.

/Michel