Re: [boost] Re: [network] An RFC - updated
On Fri, 2005-04-22 at 12:42 +0300, Peter Dimov wrote:
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.
Rationale: buffer management is a pain with multiple callbacks active ;-)
This would give a significant performance hit as there will now be two copies of the data. The 1st from kennel space to the library and the second in the callback from the library to the user. /ikh
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. Peter
Iain Hanson wrote:
On Fri, 2005-04-22 at 12:42 +0300, Peter Dimov wrote:
Rationale: buffer management is a pain with multiple callbacks active ;-)
This would give a significant performance hit as there will now be two copies of the data. The 1st from kennel space to the library and the second in the callback from the library to the user.
And in some cases setting the buffer sizes of the socket to 0 will also remove the buffering in the kernel and only use usermode buffers. And making to many choices on memory and thread managment isn't a good idea in a general purpose networking library. /Michel
Iain Hanson wrote:
On Fri, 2005-04-22 at 12:42 +0300, Peter Dimov wrote:
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.
Rationale: buffer management is a pain with multiple callbacks active ;-)
This would give a significant performance hit as there will now be two copies of the data. The 1st from kennel space to the library and the second in the callback from the library to the user.
Sometimes, yes, but not always. You don't have to make a copy in the callback, and for small packets and low bandwidth, the extra copy may not be significant. Also note the "by default" in the above. I am not against manual buffer management, just against the absence of automatic buffer management.
participants (4)
-
Iain Hanson -
Michel André -
Peter Dimov -
Peter Simons